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I. INTRODUCTION 



A. GENERAL DISCUSSION 

This thesis presents the design and part of the implementation of software for 
the Gemini Computer, under CP/M-86 and GEMSOS Operating Systems, to 
allow the dynamic sharing of system resources in a multilevel secure computer 
system, using Janus/ Ada language as a host language. 

Security has traditionally been provided by physical measures (fences, police, 
dogs, alarms, etc.) to prevent unauthorized access to computers. But today this is 
no longer sufficient. The extensive use of networks brings the possibility of 
uncontrolled access to the resources of any installation from remote sites. 
Discretionary security measures, i.e., "password" types, alone are not totally 
adequate where security of information is paramount [Ref. lj. Steps must be 
taken to strictly reinforce a non-discretionary policy as well. This situation 
provides enough motivation to look for more reliable methods to control and limit 
the access. 

This necessity of Trusted Computers is even more critical and compulsory in 
military organizations, where many delicate decisions depend on the quality of the 
information, which if known or modifiable by unauthorized users, creates a risk to 
the countrv ; s security. 
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The Naval Postgraduate School is involved in the use of microcomputers in 
its Microcomputer Laboratory in which several of them are networked together 
through a concentrator for information sharing. These systems are to be used by 
people with different levels of security clearance who handle information with 
multiple security classifications. This application necessitates the use of a mass 
storage system with the ability to limit access to classified programs and data. 
The only effective way to insure multi-level internal security is by employing a 
Trusted Computer Base [Ref. 2] such as provided by the Gemini computer. 

Figure 1.1 shows the proposed configuration of a microcomputer system 
having the Gemini computer at its base. The Gemini System provides the base 
layer of an operating system which implements internal information security 
through a "security kernel" design [Ref. 3:pp. 1-2]. To construct the 
architecture proposed in Figure 1.1 requires implementing the top layer of the 
operating system for handling the Input/Output operations. Three design 
elements can be identified : 

1) The Concentrator. The concentrator will contain a software "crossbar 
switch" which allows dynamic switching for I/O interconnection between 
attached systems. 

2) The Dynamic Assignment of Security Access Levels to I/O devices. In this 
aspect, the main idea is to manage the access level of the terminal without 
relating it to an specific connection. The access level should be dynamically 
recognized by the characteristics of the user, rather than be limited to a 
secondary issues such as location or terminal number. This is the main topic 
addressed by the current research. 
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Figure 1.1 Microcomputer System Organization 



3) A Segmented "File" System for Mass Storage. The purpose of this system 
would be to provide a one-level segmented storage system for mass secondary 
storage (hard disk) within a secure environment. 

B. THESIS FORMAT 

This thesis is composed of six chapters organized in such a way as to provide 
the reader with the background necessary to understand internal multilevel 
computer security concepts, in particular dynamic sharing of system resources. 
Simple guidelines in software development are introduced and a design is 
presented for the implementation of a prototype system which allows several users 
with different clearance levels to share system resources. 

Chapter I provides general information focusing on reasons why Multilevel 
Secure Systems are important. 
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Chapter II addresses the background necessary to understand Multilevel 
Security concepts and explains the Gemini System Architecture and possibilities. 

Chapter III provides specific information related to the steps necessary to 
produce basic application programs in the Gemini System. 

Chapter IV describes the design of a small "Operating System" application 
program that will handle dynamic sharing of resources, in particular I/O. 

Chapter V presents the description of the support modules used to develop 
application programs, and describes the implementation constraints and the steps 
performed to complete an application. 

Chapter VI discusses the results obtained from this research effort. It also 
suggests future investigations in this field as a continuation of the work performed 
in this thesis. 
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II. BACKGROUND 



A. TRUSTED COMPUTER SYSTEM 

Most of the basic concepts and definitions mentioned in this section are 
referenced to the standardization performed by the Department of Defense (DoD) 
related to Trusted Computer Systems. These standards are contained in "DoD 
Trusted Computer System Evaluation Criteria" [Ref. 2] published in 1983; it lists 
definitions and concepts, and provides detailed criteria pertaining to the test and 
evaluation of trusted computers. 

The security policies considered are mandatory (non-discretionary) security 
and discretionary security. 

Mandatory Security is defined as : 

Security Policies defined for systems that are used to process classified or 
other specifically categorized sensitive information must include provisions 
for the enforcement of mandatory access control rules. That is. they must 
include a set of rules for controlling access based directly on a comparison of 
the individual’s clearance or authorization for the information and the 
classification or sensitivity designation of physical and other environmental 
factors of control. The mandatory access control rules must accurately reflect 
the laws, regulations, and general policies from which they are derived. [Ref. 
2:p. 72] 

Discretionary Security is defined as : 

Security Policies that are defined for systems that are used to process 
classified or other sensitive information must include provisions for the 
enforcement of the discretionary access control rules. That is, they must 
include a consistent set of rules for controlling and limiting access based on 
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identified individuals who have been determined to have a Need-to-Know for 
the information. [Ref. 2:p. 73] 

As the names imply, mandatory policy contains a set of rules ' .at are 
imposed on all users in the organization, and discretionary policy is a specific set 
of rules further limiting access on a "need-to-known" basis. 

A multilevel secure system in a conventional computer system is impossible to 
attain without a way to enforce the policies previously indicated. Security can be 
broken without knowledge of the user because intentionally or not, there are 
possible unsecure points that will allow access to the system. A typical example of 
this problem is a "Trojan Horse" program [Ref. 4:p. 66] provided by a third 
source which may have code intentionally "hidden" with the purpose of copying 
the user s access control code [Ref. 5:pp. 55-56] when the user executes the 
program. This represents an illegal condition. 

The mandatory (non-discretionarv) and discretionary policies are 

implemented in a "security kernel" which provides mechanisms for limiting the 
access to the information. Security Kernel is defined as the hardware and 
software that realizes the "reference monitor" abstraction (i.e., the realization of 
these limiting policies), and in turn provides the idea of protection in which the 
active entities (subjects), such as people or computer programs, make reference to 
passive entities (objects), such as documents or segments of memory, using a set 
of current access authorizations [Ref. 6:p. 14]. The access class is divided into 
[Ref. 6:p. 16] : 
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a) Compromise (observe) which stares that a subject can not "observe" the 
contents of an object unless the access class of the subject is greater than or 
equal to the access class of the object. 

b) Integrity (modify) which stipulates that a subject may not "modify" an 
object unless the object's access class is greater than or equal to the access 
class of the subject. 

The multilevel secure system considered in this research is focused on the 
access of many users to common system resources without restriction of a 
designated resource to a specific kind of user. Specifically, any user can utilize any 
terminal, and the access class in not limited to physical terminals with fixed 
access levels. The user priviledges. will be determined during a logon process when 
the user provides his username and password. 

Additional explanations and details concerning secure communication 
methods and possible threats involved are described in [Ref. 7:pp. 15-28] and [Ref. 
8:pp. 19-21]. 

B. GEMINI TRUSTED MULTIPLE MICROCOMPUTER BASE 

1. General Information 

Gemini Trusted Multiple Microcomputer Base was the computer used in 
the research of this thesis. It represents an advance in technology combining 
several concepts, Multilevel Security, Multiprocessing and Multiprogramming, to 
provide an important Trusted Base Machine that can be considered for a wide 
range of computer applications where security is a fundamental consideration. 
Actually, it has been evaluated by the U.S. Department of Defense for 
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certification to meet the B3 class [Ref. 3:pp. 1-2].. and is currently undergoing 
evaluation in a specialized application for A1 class. 

The major features of this system are [Ref. 3] : 

1) Up to 8 Intel iAPX286-Base microcomputers are connected on the same 
Multibus. 

2) Minimization of bus contention by locating data and code segments in the 
local memory of each microcomputer, whenever possible. 

3) Capability of multiprocessing and multiprogramming. The Gemini Secure 
Operating System (GEMSOS) can multiplex many virtual processors onto a 
single physical processor, and support combinations of parallel and pipelined 
processing. 

4) Connection of different storage and I/O devices using an RS-232 Interface 
Board which can handle up to 8 ports. 

5) The system includes a Bus Controller, a Real-Time Clock, a Data Encryption 
Device (NBD-DES Algorithm), a Non-volatile Memory for storing system 
passwords and encryption keys. It also provides a System-Unique Identifier. 

6) Each iAPX286 microprocessor supports 4 hierarchical privilege levels. 

7) CP/M-86 Operating System is used for software development and several 
different programming languages are available to develop application 
software. 

8) Modular Expansion and Configuration Independence. 

2. Resources Management 



At the heart of the Gemini computer system is the GEMSOS operating 
system as previously mentioned. 

GEMSOS resource management services are invoked by an application 

program through a set of calls to a collection of subroutines which represent an 
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interface between GEMSOS and the application. Each language compiler has a 
unique interface library [Ref. 3:p. 4]. GEMSOS manages three classes of entities : 
segments, processes, and devices. 

a. Segment Management 

All the information is. stored in logical objects called segments which 
are handled by the application programmer using segment management calls. 
These operating system calls are described in detail in [Ref. 9:p. 10]. 

b. Process Management 

A process can be viewed as an application program that runs under 
the control of GEMSOS to perform some specific activity. The process is created 
by the application program using service calls related to the process management 
described in [Ref. 3:pp. 5-8] and [Ref. 9:p. 23]. In addition to Process 
Management, there are additional concepts related to process synchronization in 
which the application programmer has tools to sequence processes that 
communicate with each other. Synchronization is obtained utilizing eventcounts 
and sequencers [Ref. 10:pp. 115-124] associated with processes. A working 

explanation will be provided in Chapter IV. Process Synchronization calls are 
described in detail in [Ref. 3:pp. 6-7] and [Ref. 9:p. 33]. 

c. Device Management 

The design of the I/O management functions of the Kernel are novel. 
The basic idea consists of reducing the code needed in the Kernel to control I/O 
functions, by incorporating many of the details within the application program. 
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The result is a reduction of the Kernel’s size and the verification is easier. 



Security checks are performed only when the device is attached to a process (Ref. 
3:pp. 8-9]. I/O management sendee calls are described in [Ref. ll:p. 38]. 

3. Gemini Security Architecture 

Since the iAPX286 Microcomputer supports 4 protection levels, GEMSOS 
uses these levels to enforce the security critical layering of the system. Protection 
levels are called Ring 0 thru Ring 3. with Ring 0 the most privileged ring (Ref. 3: 
p.10]. Ring 0 supports the Mandatory (non-discretionarv) Policy and Ring 1 
contains the Discretionary Policy, the combination of which comprising the 
Security Perimeter and the greater portion of GEMSOS. 

Ring 1 also holds functions such as user authentication, system security 
officer functions and audit functions. Ring 2 is used for common sendees utilized 
by many users, e.g., Database Management System: Ring 3 is used as application 
layers for programs and data: both are outside of the Security Perimeter and can 
be used during the system development process (i.e., as in developing the upper 
layer of an application system as is the focus of this research), and for the 
execution environment for user's programs. 

Process management in the GEMSOS architecture is through the use of a 
two level traffic controller design (inner traffic controller or bottom level, and 
upper traffic controller). 

The inner traffic controller binds a physical processor with a fixed number 
of "virtual processors". Two of these are used to support system services (an idle 
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virtual processor and a manager virtual processor) and the others are available to 
the upper level traffic controller. The inner traffic controller also provides the 
primitives for synchronization between virtual processors emulating a 
multiprogramming configuration. 

The upper level traffic controller multiplexes a number of processes onto 
the virtual processors defined by the inner traffic controller. These functions are 
performed in each of the physical processors comprising the Gemini computer (up 
to 8) [Ref. 7:pp. 14-15], through a distributed operating system. 

4. Naval Postgraduate School Version of Gemini 

a. One APX286 Microcomputer 

b. Two 1.2 Mbyte floppy disk drives 

c. One RS-232 Interface Board (max 8 ports) 

With this configuration, GEMSOS must multiplex the processes created 
onto virtual processors and then onto a single physical processor. The 
synchronization primitives support the communication among processes. It is 
important to note that in this configuration, a multiprocessing environment does 
not exist. The potential for exploiting processor parallelism does not exist. 



19 



III. SOFTWARE DEVELOPMENT OVERVIEW 



A. GENERAL DESCRIPTION 

This chapter provides the foundation for the necessary steps to develop 
software in Gemini machines. It is important because it provides the basic 
components that are needed. Considering that Gemini is a new concept in 
Multilevel Secure machines, it is still not user friendiv. A bridge between the 
application programmer and the operating system sendee primitives had to be 
created in order to develop reliable software. 

The basic Gemini operating system is limited and only supports those 
operating system functions which are concerned with system security. Thus, only 
an operating system base is provided upon which an upper level i.e., I/O handler, 
file manager, etc. must be provided to support specific user requirements. 

Subroutines or modules were prepared to perform the interface between the 
programmer and the operating system primitives. A complete explanation of 
these modules is provided in the design and implementation chapters. 

The objective of this chapter is to present an ordered method of developing 
application software within the environment. It should be considered as a guide 
and not as a fixed set of rules. The facts considered here are taken from the user's 
manual [Ref. 9]. 
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B. HIERARCHICAL STORAGE STRUCTURE 



The Gemini System provides a one-level secondary storage system for 
information (In the XPS configuration, secondary storage refers to floppy disks). 
File concepts are not supported by Gemini, but instead segments are used which 
are considered as objects having logical attributes related to them (i.e.. security) 
and being of a maximum 64 K bytes size. Segmentation is extended to secondary 
storage, providing the one-level storage system. 

The segments are handled by the system as a hierarchy, where each segment 
is identified by a unique path name. This segment’s "handle" corresponds to the 
index of an entry in the Local Description Table (LDT) of the process that creates 
and/or uses the segment. As such, a single segment can have many different 
handles depending on where and how many processes enter it into their respective 
LDT tables. But it has only one unique path name in the hierarchy. 

The representation of segments follow a hierarchical structure in which the 
root is the System Root (transparent to the user) and the whole collection of 
segments is assembled as an inverted tree. Each user's program is part of the 
hierarchical structure and it is declared as a segment that is statically created at 
system generation time using the Svsgen Submit file explained in [Ref. ll:pp. 12- 
14], 

System generation consists of creating a hierarchical structure of all segments 
known to the system at system runtime, in particular at system "Bootload". It 
basically is the inclusion of the segment hierarchy comprising the upper levels of 
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the application target system, into the provided base level hierarchy that is known 
as GEMSOS. This is accomplished by utilizing segments declared in the submit 
file, i.e., the sysgening process creates a hierarchy using the segments indicated in 
the submit file. 

Figure 3.1 shows a typical hierarchical structure representing the entries that 
GEMSOS requires to run programs. This structure is fixed and must be 
considered in the development of any application program. Figure 3.2 shows the 
addition of segments necessary to execute a specific application. Entry 5 in the 
hierarchical structure is always dedicated as the "root" of user applications. This 
entry is the root or mentor of all the segments that are needed to implement the 
upper levels of the system application program. Under the Gemini concept, a 
segment can support up to 12 descendants (entries) numbered from 0 thru 11. To 




NV.DS Yllogin applic 

coda cod« 

Figure 3.1 Hierarchical Structure 
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support this concept there is an. "aliasing" table that relates the segments to their 
mentors; a segment can only have one mentor [Ref. ll:p. l]. 

When an entry is used, it cannot be assigned again until a delete segment call 
marks this segment as available. The numbers indicated in both figures 
correspond to entry numbers of segments associated with a mentor (from 0 thru 
ii); segment numbers have a different enumeration, which correspond to their 
entries in the LDT. 

Each segment in the system has a unique pathname that identifies it, but this 
identifier is not used by the application processes. Instead a process-local segment 
number is used. When two processes share the same segment, each one recognizes 
the segment by the number assigned in its own LDT. 
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Figure 3.2 Hierarchical Structure including an application 
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In Figure 3.2 the path 5.7 corresponds to a segment that holds the code of a 
child application program and must be declared in the Submit file. Entry 5 is the 
mentor of Entry 7. This creation is static and the path indicated must be known 
in the application program. On the other hand, the path 5,5,7 is used to hold data 
and will be created dynamically during execution of the application program. A 
more complete explanation is presented later in this chapter and in Chapter IV. 

C. I/O DEVICE ASSIGNMENT 

The process of "Attaching Devices" must be accomplished before an I/O 
device becomes "known" to the system. It involves assigning a logical process to 
the I/O device so that the device then is known by its process. The process then 
contains the device drivers. This step is necessary before any I/O operation. A 
device can be declared either as a Read (input) or Write (output) device, as part 
of the information provided to the Attach primitive call into GEMSOS [Ref. 
9:pp. 39-41]. A device can be attached to only one process at a time, an error will 
occur if an attempt is made to attach a device more than one time. 

The inverse step is called Detach devices, in which the associated process is 
eliminated and the device becomes available for further assignments [Ref. 9:p. 42]. 

D. PROCESS CREATION 

This section describes the steps that should be considered when creating a 
process. One process is created from another. The "creator" process is known as 
the parent and the created process is known as the child, also having its own 
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unique identifier. The child process receives its fixed amount of resources from the 
parent, subtracting from the parent's overall resources. A process is a collection 
of segments known to the process. The segments are managed using a set of 
primitive functions or "calls" provided by the system. An address space is created 
to hold a segment. The application programmer must make use of GEMSOS 
primitives in creating and using this address space. 

The sequence of steps that must be followed in order to create a process, 
starts with the creation of a segment in the address space using the resources 
available on secondary storage. The primitive create is called, resulting in the 
creation of the address space for this segment. The next step links the space 
created with a specific process that will use it. In other words, a recognition of this 
segment is performed in which the process makes the segment known to itself by 
entering it in the next available entry in its local description table (LDT). The 
result is the identification of this address space by a number that is called 
segment number which will be used when the segment is referenced. The 
primitive used is makeknown. The result is the identification of this segment for 
the process and to the system. 

The last step is related to the utilization of this segment; a segment must be 
in main memory in order to be used. This function is performed using the 
primitive swap-in. which produces the loading of the segment from secondary 
storage into main memory. 
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When the segment is no longer needed by the process, i.e.. process completed 
execution, an inverse action must be performed in order to release the space used 
by the segment. As in the steps declared above, a logical sequencing must be 
followed, starting with the release of the memory used by the segment. This is 
performed by the swap-out primitive in which the segment is written back out 
to secondary storage. The next step is the elimination of the association 
segment-process. Elimination of a segment from a process' address space is 
performed by the terminate primitive; the association is broken, and the entry 
number used in the LDT of that process is available again. 

The total removal of a segment from the system address space is 
accomplished by using the delete primitive; the result is the removal of the 
segment from the system and process local name space, and the returning of its 
address space back to the system resources. The steps necessary to create a 
process are indicated in the Figure 3.3. 

1. Create / Makeknown Segments Module 

A process needs a minimum of two segments, a code segment and a stack 
segment, in order to be created. The code segment for a process is declared in the 
Sysgening Submit file and is created automatically by the system during the 
system generation (statically). 

The stack segment, as well as any additional segments, are created in the 
user’s program (dynamically) by making the appropiate operating system calls for 
Create and Makeknown. These calls will be explained later in this chapter. 
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Figure 3.3 Process Creation Main Modules 



2. Address Space Specification Module 

The address space specification contains a list of the segments that will be 
passed by the parent process to the new process (child). In addition, the attributes 
of each segment to be passed are loaded into this module. The address space 
specification of a process is composed of 5 segments : a stack segment, a code 
segment (both are compulsory), 2 free segments (can be used as application 
mentor and for holding data) and a trap segment that is automatically created (it 
is declared in the submit file) and handled by the system. It holds information for 
GEMSOS that will be used when a user trap fault is detected. These segments 
correspond to entries 20 thru 24 of the Local Description Table to be associated 
with each process. 
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Register Record Module 



3. 



This module performs the initialization of the register record which 
defines the state in which the program will begin its execution. The register 
record contains the following fields [Ref. 9:p. 27) : 

1) Instruction pointer (ip) .- Specifies the code offset address. 

2) Stack pointers : 

- SP .- The initial stack pointer for the new process. 

- SPl .- Points to the base of the ring 1 stack segment. 

- SP2 .- Points to the base of the ring 2 stack segment 

(if one is used). 

4. Resource Record Module 



In this module the new’ process (child) attributes are declared, and the 
amount of resources that the parent process will have to provide to the new 
process are defined [Ref. 9:pp. 27-28). The resources received by the child process 
are subtracted from those of the parent. The amount of resources needed by a 
child w’ill depend of the kind of application that a child w’ill perform. The 
resources involved are [Ref. 9:pp. 27-28) : 

- Amount, of memory (blocks) that the child is allow’ed to swapin. 

- Maximum number of processes that the child is allowed to create. 

- Total number of segments that the child will have. 

In addition to the resources, a child process number must be declared that 
uniquely indentifies this child. Also the child's access class must be specified which 
must be wdthin the parent's range. The resources passed to the child process are 
recovered by the parent w r hen the child finishes its execution and self deletes. 
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5. Create Process Module 



The primitive Create Process is called, resulting in a new process being 
created. A success code is returned by the operating system to indicate success or 
failure for this operation. The parameters passed by this module are the record 
description of the process to be created (rl cp struct) and a variable called 
"success" that will hold the execution’s result of this primitive. The application 
programmer must fill all the fields related to the characteristics, attributes and 
resources that the new process will have. A description of the record 
"rl cp struct" is given in the library AGATE. LIB provided by Gemini 
Computers Inc., and in Ref. 9:pp. 24-28]. Error codes are explained in [Ref. 9:pp. 
84-93]. All the modules described above can be executed in any order before the 
execution of this module. 

E. LOCAL DESCRIPTION TABLE (LDT) 

Since the actual use of the GEMSOS primitives requires interfacing to the 
upper level of the application system under development, special interface 
routines had to be implemented. The next three sections describe these interface 
routines. A process has a fixed collection of segments which comprisess its address 
space; these are known by the process as entries in its Local Description Table 
(LDT). Each process can have up to 52 segments (from 0 thru 51) known to it at 
one time. Segments 0 to 19 are used by the Kernel, segments 20-24 correspond to 
segments pre-defined in the address space definition of the new process [Ref. 9:pp. 
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26-27] . and segments 25 through 51 are available to the application programmer. 
This segment distribution is fixed in the LDT and can not be modified. A fatal 
error will result if a system segment is used for other purposes (segments 0 thru 
24). 

F. CREATE/DELETE SEGMENT 

Because a process is a collection of segments, segment creation is an 
important step that should be considered during process creation. Each segment 
has its own attributes which are specified in a Createseg struc record; this 
record must be declared before calling the primitive Create_segment. The 
segment is created with the specified attibutes. and the addition of a new branch 
in the hierarchical structure is made {Ref. 9:pp. 14-15]. The inverse action is the 
Delete segment call, where a segment created previously is removed from the 
hierarchical structure, this call should be performed when the specified segment is 
no longer needed [Ref. 9:pp. 16-17], This call must be used when a process 
finishes its execution because the applicable segments are not automatically 
removed. 

G. MAKEKNOYVN /TERMINATE SEGMENT 

The Makeknown segment call adds the specified segment to the address 
space of the calling process (including the segment number in its LDT table) [Ref. 
9:pp. 17-19]. Like all the primitives it has its own record Mk_kn structure, 
which must be initialized with the pathname that the segment will use in the 
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hierarchical structure. Complete details are provided in Chapter IY. The inverse 
step eliminates the pathname created in the makeknown process and also frees the 
segment number from the LDT table. This primitive is Terminate segment 
and it is described in [Ref. 9:p. 20]. 

H. SWAPIN/SWAPOUT SEGMENT ' 

A segment is created in secondary storage by first utilizing the primitive 
Swapin segment, to provide main memory space for the new segment, and the 
writing the new segment out to secondary ' storage by utilizing 
Swapout segment primitive. This function call writes any segment currently 
stored in main memory out to secondary storage [Ref. 9:pp. 21-22]. releasing the 
main memory. 

I. SYNCHRONIZATION 

Synchronization among processes is maintained by the use of eventcounts and 
sequencers [Ref. 10. pp. 115-124], which are maintained in segments used to 
synchronize processes. The segments used must be common to all the processes 
involved in the same synchronization. An eventcount is maintained by an integer 
counter under control of the cooperating process. Completion of an operation 
(event) is signaled by incrementing the eventcount. The updated eventcount 
provides a signal to a waiting process that the operation which it has been waiting 
for is complete. The primitives used are described in [Ref. 9:pp. 33-37]. 
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IV. SYSTEM DESIGN 



A. INITIAL DESIGN 

1. Objective 

The initial objective of the design was to build the upper levels of an 
operating system based on the Kernel provided by GEMSOS, which would 
provide multiuser mass secondary storage capability, in a multilevel, secure 
internal environment. User access through terminals was initially to be without 
physical security barriers, and terminal access levels determined dynamically 
based on user access levels. I/O device servicing was to be interrupt driven. 
Figure 4.1 shows the initial design containing 3 main modules that compose the 
upper levels operating system : Basic Input/Output (BIOS). Console Command 
Processor (CCP). and Basic Disk Operating System (BDOS). Implementation of 
these modules duplicates the same organization used in CP/M or DOS Operating 
Systems. Secondary storage is to be by segments, providing a "one level" storage 
system, i.e., no file concept. Security is provided by the GEMSOS operating 
system. 

2. Initial Design Constraints 

One major limitation to the above design was the restricted way in which 
GEMSOS handles interrupts. I/O interrupt handlers currently can not be used 
from ring 2 or 3 levels, and as such can not be developed in the BIOS module. 
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Figure 4.1 Initial Design 



Future versions of GEMSOS from Gemini Computers Inc. will resolve this 
constraint, but the efforts in this thesis were restricted to programmed I/O type of 
device handling. 

The second limitation was related to the number of users that the BIOS 
module can handle. Since the communications are performed through a RS-232 
interface board with 8 ports, and each user needs one physical port (read/write), 
the maximum number of users is 8 (without considering a device for the main 
application program). This limitation still exists in the Naval Postgraduate School 
system configuration. 
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B. COMPROMISE DESIGN 



1. Objective 

The primary objective is the same as declared in the initial design, except 
that the BIOS module is replaced by a dedicated program to handle each 
terminal, instead of several terminals handled by one program. Each of the 
programs are identical routines which operate at a System high access level to 
identify a new user through the terminal, and create a corresponding access level 
process to which the terminal is then "attached". Figure 4.2 shows the actual 
design used. 

With this design. Gemini's capabilities of multiprocessing can also be 
taken advantage of. Each user can have a virtual processor attached to itself and 
work in a multiprogramming configuration, limited only by the resources available 
(processes, segments, memory, ports, etc.). Considering the NPS system, it is 
possible to emulate multiprocessing with a single processor in which GEMS OS 
multiplexes the processes using synchronization methods. The distribution of the 
system resources among individual users can be dynamically assigned/reassigned 
based on the needs of the user. The amount of resources assigned to the users 
must not be greater than the resources that the complete system has. 

2. Actual Design Constraints 

As previously mentioned, the number of users is limited to 8 because of 
the NPS system configuration. 
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Figure 4.2 Actual Design 



The second limitation is related to the size of the LDT, i.e., the number 
of entries that the application programmer is able to use. If a process nominally 
needs 3 segments (stack, code, and data) this means that not more than 9 
processes can be created in the main application program. Considering the actual 
design in which a process creates another process, it means that for each user 
process six segments are needed. Since there are only 27 segments available in the 
LDT for each process, then the maximun number of processes is 4 (3 users and 
the BDOS process). By including the data segment in the stack segment, only 4 
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segments are needed for each process, the result is a maximun of 5 users and the 
BDOS process. 

An additional limitation comes from the fact that there are no developed 
modules to handle the hierarchical structure or to handle the LDT table of each 
process. This means that the next available entry or segment number in the LDT 
or the next entry related to a segment mentor are not dynamically provided by 
the system and must be obtained in some way. Instead of designing and 
implementing these modules, temporary modules were designed to create 
parameters that were useful to the system. A complete set of modules was 
provided by Gemini Computers Inc. when the system was delivered, but these 
were coded in Pascal MT+ and the implementation language for this research was 
Janus/Ada. Conversion from Pascal MT-j- to Janus/Ada was one alternative but 
there was no documentation of the function and structure of these modules 
resulting in the creation of parameters instead of conversion. 

These temporary modules create parameters statically for those that the 
system should provide automatically. Using these temporary modules it is possible 
to evaluate system functions and observe how the the hierarchical structure is 
maintained. 

3. Hierarchical Structure Design 

Figure 4.3 shows the complete structure design of the system, considering 
the segments needed to work with 3 users. The numbers indicated inside the 
circle represent an entry number in the mentor’s LDT (maximum 12 segments), 
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System mentor 




and the numbers shown outside the circle represent the process-local segment 
numbers of the CCP application program. They are used to identify each 
segment. This can be seen in Figure 4.4. The hierarchy shows the segments 
33.35,37,39 as segments that hold the code developed to support the application 
program in each specific level : User Handler processes and the BDOS process. 
These segments are specified in the Submit file and are created in the sysgening 
process together with those segments needed to hold the code of the three Active 
Users processes. The segments 32,34,36,38 are used to hold the stack segments, 
and the segments 40,41,42,43 are used to pass information between processes. 
The segment 51 is used by CCP to effect synchronization with the other processes, 
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Figure 4.4 Address Space Specification for each user process 



awaiting the eventcount of this segment until some other process advances it, 
thereby letting the CCP execute its functions. 




Figure 4.5 Hierarchical Structure : User Processes 
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A unique pathname identifies each segment in the hierarchical structure. 
An example of this concept is shown in Figure 4.5. This tree represents the user 
handler application code segments and their segment numbers in each process. 

Although the segment numbers are the same (32,33,34), they differ by the 
pathname associated with them, i.e., pathname 5. 7, 3,1 (userl) pathname 5.8,3. 1 
(user2), and pathname 5, 9, 3,1 (user3). 

C. SYSTEM SOFTWARE DESIGN 

1. Application Programs Design 

The design was divided into 2 types of programs, applicative programs 
(Main Application program CCP. User Handler program. Active User application 
program, and BDOS application program) and utility programs (common 
procedures and functions). Structured programming techniques were used to 
develop the application programs. These techniques are well supported by the 
implementation language selected. Janus/Ada. Figure 4.6 shows the modules 
supporting the Main Application program (CCP) that are used to manage the 
whole system. 

These modules are : 

1) Load parameters 

2) Create segments 

3) Create processes 

4) Synchronize processes 

5) Delete Processes 

6) Terminate segments 

7) Delete segments 
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Figure 4.6 Main Application Program 



Each module was developed as an independent procedure or function, 
requiring, in some cases, additional subdivisions because of the high complexity of 
the module. These modules represent upper level interfaces to GEMS OS system 
calls. 

a. Load Parameters Module 

Figure 4.7 shows the table of parameters created by this module. In 
addition it creates another table with segment numbers that will be used to 
synchronize the main application program (CCP) with the Active User programs. 

b. Create Segments Module 

This module creates the segments necessary either to represent some 
part of the hierarchical structure or to perform synchronization among processes. 
The size of these segments is fixed (l byte) because they only function as mentors 
of other segments or as synchronization segments. A synchronization segment is 
created as a common segment, which must be known for all the processes in the 
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Figure 4.7 System Parameters 



application program. This is necessary because the execution of the main module 
CCP must be accessible to all processes communicating with the CCP to perform 



some operation. 

The segments created are : 



1) Function : mentor of stack and data segments 
of the User Handler processes 
Mentor : initial segment (2) system segment 

Entry : 5 

Classif : unclassified 

Number : 31 



2) Function 
Mentor 



synchronization 

segment 31 (created previously) 
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Entry : 11 
Classif : top-secret 
Number : 51 

c. Create Process Module 

This module contains a loop that is executed 4 times which creates 
three User Handler processes (3) and the BDOS process. All of these processes will 
have multilevel access classes to handle users with different levels of clearance. 

This module is sub-divided into sub-modules that are easier to test 
and understand. The sub-modules are : 

1) Create and Makeknown segments 

2) Fill the Address Specification 

3) Initialize the Register record 

4) Fill the Resource record 

An explanation of each module was provided in Chapter III. The 
main point here is that the process will be created using the paramenters loaded 
previously and each process will receive the following resources : 

Memory : 100 bytes 

Segments : 300 segments available 

Process : 1 (max number of processes that can create) 

d. Synchronization Module 

The synchronization used can be cataloged in one of four types : 

1) Main Application Program-User Handler Process. This is performed in two 
ways : 

- After process creation the User Handler Process communicates that it was 
created and returns control to CCP. 
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- During process synchronization the User Handler Process will communicate 
to CCP that a User (terminal) is active or inactive. 

2) Main Application Program-Active User Process. This is performed when the 
Active User created by a User Handler process sends a message (command -f- 
information) to CCP in order to execute some specified operation, i.e.. The 
CCP performs this command (calling BDOS if necessary) and returns a 
result to the Active User. 

3) Main Application Program-BDOS. This synchronization is performed when 
the Active User executes a command that requires BDOS participation, such 
as a read/write segment to secondary storage. CCP receives the message from 
the user and directs it to BDOS. When BDOS executes the command, it 
returns the result to CCP which in turn directs the result to the Active User. 

4) User Handler Process- Active user Process. This is performed when the 
Active User is created and communicates that it was created, returning the 
control to the User Handler. The same communication is performed when the 
Active User finishes execution (entering "bye"). 

When the communication is between CCP and a User Handler or an 
Active User, the CCP must recognize which user sent the message in order to 
return the result. The synchronization is obtained using the following segments : 

1) Stack Segment. To synchronize the execution of that process. 

2) Data Segment. To determine which user was activated. The CCP stores the 
previous value of the data segment of each process. When User Handlers or 
Active Users send a message, it advances the eventcount (also the 
synchronization segment eventcount) then CCP compares this value against 
the value stored previously. If the result is different it means user activated, 
otherwise CCP checks the eventcount of the next user until an active user is 
found. 



3) Synchronization Segment. To synchronize the execution of the CCP. All the 
processes know this segment in order to activate the CCP execution, 
advancing the eventcount of this segment. When CCP finishes execution, it 
advances the eventcount of the process that activated it previously and then 
waits until another process calls it again. 



43 



The CCP knows the synchronization segments used by each process 
since they are specified in the system parameters. The segments used are : 
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The synchronization mechanisms used here are Await, Advance 
and Read eventcount, as provided in GEMSOS. 

e. Delete Processes Module 

This module will delete the processes created before. It is executed 
when users enter "bye". In addition to this, it will also terminate and delete the 
segments created in the process creation (stack and data), and will terminate the 
code segment. The success of this module depends on the previous self deletion of 
the User Handler process. 

f. Terminate Segments Module 

This module terminates the segments created previously (mentor and 
synchronization segments). The result is that segments numbered 31 and 51 are 
now available in the LDT. 
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g. Delete Segments Module 

This module returns the space used by the segments terminated 
before, and marks free the entry numbers used to create these segments. 

2. User Handler Application Program 

The design is like that of the CCP design. The differences are related to 
the way the modules perform internally. The function of this application program 
is to create a single access level Active User according to the user clearance level 
determined during the Logon process. It is also divided into the following 
modules : 

a. Load Parameter Module 

This module creates a table with parameters that are needed in the 
Active User process creation. The parameters are the same for all users’ processes 
since each User Handler has its own LDT table. This means that they have 
independent segments. Again, Figure 4.5 shows the structure and numeration of 
each segment. 

b. Create Segments Module 

This module creates the segment that will be used as mentor of the 
Stack and Data segments for the Active User process. One difference between this 
module and the Create segment module in the Main Application program (CCP) 
is that it does not create a specific synchronization segment. Another difference is 
related to the mentor used to create the User Active process. The User Handler 
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program’s code was used, because it is unclassified and can satisfy requirements of 
security. 

An unclassified segment has minimum access class constraints and 
can be mentor of classified segments. As such the segment that holds the User 
Handler code was used since it is unclassified and satisfies security requirements. 
The inverse case occurs when a classified segment is used. It can only be mentor 
of those segments with equal or greater classification. This means that segments 
with less access class cannot be created, limiting the participation of users with no 
classification level. In a multilevel system, the mentor segments must be capable 
of handling different kinds of users and segments associated with those users. 

c. Create Process Module 

This module creates a single access level Active User Process (only 
one). The access level is determined when the user enters the system. The 
difference between this module and the one contained in the Main Application 
program is the resources assigned to the created process : 

Memory : 60 bytes 

Segments : 100 segments available 

Processes : 0 (cannot create child processes) 

d. Synchronization Module 

The synchronization used was explained previously; the segments 

used are : 

1) Code Segment. To synchronize the execution of User Handler Process. 

2) Stack Segment. To synchronize the execution of the Active User. 
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This synchronization takes place when the User Handler process 
releases the attached terminal, creates and activates the Active User process 
(advancing its stack eventcount), and waits until the Active User (child) finishes 
execution (entering '’bye" and self deleting). When this happens, it terminates 
and deletes the segments created to support the execution of the Active User 
(stack, data, mentor segments), and communicates to CCP that this user is 
inactive. 




terrain*! 



Figure 4.8 User Active Application Program Modules 



47 




Active User Application Program 



This program was designed following structured programming techniques. 
Figure 4.8 shows the modules that compose the Active User application program. 
These modules are : 

1) Attach terminals (read - write) 

2) Loop 

- Prompt the user 

- Get user input 

- Load data segment 

- Synchronize 

- Put result 

3) Detach terminals 

4) Self delete 

Following the same structure used in the description of the Main 
Application program and the User Handler Application program, the modules 
indicated above are described individually : 

a. Attach-terminal Module 

This module assigns a terminal to the Active User process, the object 
being to allow the user to perform I/O operations. There is a specific 
Attach device call for assignment of read and write. 

b. Loop Module 

This module handles the main process. It starts with the input 
entered by the user, and finishes when the user receives a result for the input 
entered. The intermediate steps necessary to get the output result from CCP are : 

1) Load Data Segment. The segment created to pass data. 
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2) Synchronize with CCP. Data segment is passed to CCP and the 
synchronization segments are activated (advance synchronization and data 
segments eventcounts; await stack segment eventcount). 

c. Detach terminal Module 

This module detaches the device previously attached, returning 
control of this device to the Operating System, making it available for future 
assignments in other processes. There must be a balance between Attach and 
Detach calls, otherwise a system error will occur. 

d. Self delete Module 

This module holds the ending of a child process. Self delete is 
required if the next step is delete the child (Active User) process from the address 
space of the parent (User Handler). When the delete process is complete, the 
parent recovers all the resources that were assigned to the child in the 
Create_process step. In addition to the Self_deletion call, a segment number must 
be specified in order to perform the synchronization. This is due to the fact that 
when the process finishes, it automatically Advances the segment eventcount 
indicated in the Self delete call. 
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V. IMPLEMENTATION 



A. GENERAL DISCUSSION 

Implementation of the model was designed considering one application 
program for each process. The following programs were developed : 

1) Main Application Program- CCP (Appendix A) 

2) User Handler Application Program (Appendix B) 

3) Active User Application Program (Appendix C) 

4) BDOS Application Program (Appendix D) 

To this end. it was necessary to construct the following support programs : 

1) Primitive Calls 

2) Auxiliary' Functions 

1. Primitive Calls 

The object of this program is to be used as an interface between the 
GEMSOS primitives at the Kernel level of the system and the application 
programs. All primitives use a record structure initialized by the programmer 
before calling for the specific operation. The set of programs developed to perform 
these functions are called "PROCE"; they were built by modifying the 
demonstration program provided by Gemini Computers Inc. and adapting them 
to the requirements of the proposed model. 

The program "PROCE" has two extensions: "PROCE. LIB" contains the 
specifications that can be visible to the user, and "PROCE. PKG" contains the 
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code developed to handle these specifications. T .is is an ADA feature that helps 
to reinforce security aspects (Information Hiding Principle). 

The procedures developed in these modules are : 



PROCEDURE 



PRIMITIVE SUPPORTED 



CR-SEGMENT 

DL-SEGMENT 

MK-SEGMENT 

MAKEKNOWN-SYNCH 

TERMINATE-SYNCHR-SEG 

FILL-INIT 

CR-PROCESS 



CREATE-SEGEMENT 

DELETE-SEGMENT 

MAKEKNOWN-SEGMENT 

Used to makeknown the synchronization 

segments (CCP-to- Active User) 

Terminates the segments indicated 

above 

Fills the resources record needed by 
Creat e-process primitive 
CREATE-PROCESS 



The program listing is contained in Appendix E. Those GEMSOS 
primitives not requiring record initialization (i.e.. Terminate-segment and all 
the primitives used for synchronization) were not included. The primitives 
Attach-device and Detach-device. were separated into the Auxiliary Functions 
program because they may be called in future applications that may not need the 
use of the other primitives declared above. 

2. Auxiliary Functions 

This program contains additional data structure needed by the main 
application program, i.e.. command record, password's record description, 
constants used, etc.. It also contains procedures and functions to perform I/O 
operations (read and write), and functions to create parameters replacing the 
modules that the system needs but were not delivered in the NPS Gemini package 
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(The LDT entry allocation procedure for example). These were described in the 
design constraints of Chapter IV. As in the previous program, some procedures 
and functions provided by Gemini Computers Inc. were used as a basis to 
construct this program segment, with the addition of code and records required to 
support the current research. This program, called "FILES", has two extensions, 
"FILES. LIB" contains the specifications and records, and "FILES. PKG" contains 
the code developed. 

The procedures and functions included are : 



NAME TYPE 



DESCRIPTION 



GET-STR 

PUT-STR 

PUT-DEC 

PUT-SUCC 

GET-INPUT 



ATTACH-TEW/TER 



LOAD-PARAM 



LOAD-ACCESS-CLASS 

LOAD-PARAMl 



LOAD-CHILD-ACTIVE 



Procedure 

Procedure 

Procedure 

Procedure 

Function 



Procedure 



Procedure 



Procedure 

Procedure 



Procedure 



Gets a string from the terminal 
Displays a string in the terminal 
Displays a number in the terminal 
Displays a string and a number 
Gets an input string from the terminal 
and echoes the input if the echo option 
is on. It also converts all the input to 
lower case 

Supports the primitive ATTACH 
DEVICE specifying if the device is 
to read or write 

Produces a table of parameters with 
information needed by the main appli- 
cation program (segment number, entry, 
mentor) 

Produces a table with the security 
access level depending on the user level 
Produces a table of parameters with 
information needed by the user handler 
program (segment number .entry, mentor) 
Initializes the Active User record to 
false. It lets the CCP load the Active 
User segments each time a false record 
is found 
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LOOK-FOR-LEVEL 



Procedure Simulates the Logon process, loading the 
access class of the user depending on 
Username and Password 
CONVERT Procedure Assembles the command line using 

the input message typed by the user 

The program listings are contained in Appendix F. 

B. IMPLEMENTATION CONSTRAINTS 

Two factors dictated splitting the implementation into several steps thus 
making the system easier to develop and test. These factors were : 

1) Lack of System Documentation and prior experience. 

2) Time required to develop, implement, integrate and test. 

At the time this research started, sufficient information about the system 
did not exist. As such numerous system "quirks" posed additional time delays in 
the implementation process. L T pper level interfaces to GEMSOS had to be 
implemented, at times by experimentation. Program development using an 
unfamiliar set of procedures and new functions is error prone, requiring 
programming tools that are still not available in this machine. Another 
implementation constraint was the time required for program development. 

A main factor related to the speed of development is the fact that a 
program, in addition to compiling and linking, requires a special process, called 
"Sysgen" prior to execution. Sysgening takes longer than 10 minutes each time, 
even if only a single line was changed. Since debugging tools were limited, it often 
took several attempts to find a mistake or the exact way of performing a specific 
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operation. As previously described, the "sysgen" process has the functions of 
creating and formating logical volumes in secondary storage, and creating a 
bootable Gemini System Segment Structure on formatted volumes. This 
second function is called each time a program must be loaded to execution [Ref. 
8:p. l]. The use of the system program (sysgen) is explained in [Ref. 8:pp. 8-18]. 

C. IMPLEMENTATION STEPS 

The basic approach starts with a model using the demonstration program 
provided by Gemini Computers Inc. The primary steps followed were : 

1. Single User. Single Security Access Level 

This step established the ability to create a child process and to 
establish communication between parent and child processes. The main issue here 
was the stack size. Its size had to be determined experimentally (AFFF hex), since 
it is not clear as to the correct way to measure the size. The size of the stack is 
determined by the following constants : 

stack-size = vector-size 4- segment-manager-size -1- constant 

= 4 bytes 76 bytes AFFF bytes 

The size of the last constant was derived empirically, and is 
apparently a combination or the amount of memory needed to create a child 
process and the number of processes that can be activated simultaneously in the 
system. 
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2 



Several Users. Single Security Access Level 



This step proved the creation and synchronization among several 
processes. The key points were : 

a) The hierarchical structure of the system required special procedures for 
handling. A procedure was created to dynamically determine the next 
segment available in the system. This procedure was written to associate the 
next segment number to be used in process creation, and the entries used by 
each segment. The resulting table of parameters created by this procedure 
was previously shown in Figure 4.7. 

b) A synchronization method among processes was needed, which included the 
structure needed to determine which process was activated (two 
synchronization segments for each process). 

c) Communication between processes was developed (passing information). The 
procedure Move_bytes is considered to pass information from one process 
to another, an example and further explanation is provided in [Ref. 9:pp. 5- 
6 ]- 

3. Several Users. Multilevel Security Access 



This step introduced the security constraints needed to work in a 
multilevel secure system, the key points were : 

a) Creation of a Child process (Active User) by another child process (User 
Handler) previously created by a main application program (CCP). This 
addresses the resources passed by the parent process. A balance was 
achieved between the resources passed by CCP when it creates a User 
Handler process, and the resources passed by the User Handler process to 
an Active User process during its creation. In other words the following 
constraints were applied : 

(User Handler (1 -f 2 + 3) -f BDOS resources) < CCP resources 

Active User resources < User Handler resources 

b) Development of three kinds of synchronization : between Child (Active User) 
and Parent (User Handler): Grandchild (Active User) and Grandparent 
(CCP); Parent (User Handler) and Grandparent (CCP). Different segments 



55 



pathname 





0-19 kernel 






20 - 24 address 
specif . 






25 - 30 

not used here 




31 


users' mentor 


5 , 5 


32 


stack user 1 


5,5,1 


33 


code user 1 


5,7 


34 


stack user 2 


0,5,2 


35 


code user 2 


5,8 


36 


stack user 3 


5,5,3 


37 


code user 3 


5 , 9 


38 


stack BDOS 


5,5,4 


39 


code BDOS 


5,10 


40 


data user 1 


5,o,5 


41 


data user 2 


5,5,6 


42 


data user 3 


5,5,7 


43 


data BDOS 


5,5,8 


44 


mentor chid users 


5, 7, 3/5, 8, 3/5, 9, 3 


45 


stack chid user 1 


5,7,3, 1 


46 


data chid user 1 


5, 7, 3, 2 


47 


stack chid user 2 


5, 8,3,1 


43 


data chid user 2 


5, 8,3, 2 


49 


stack chid user 3 


5, 9, 3,1 


50 


data chid user 3 


5, 9, 3, 2 


51 


SYNCHRONIZATION 


5,5,11 



Figure 5.1 Main Application Program LDT 



were used to synchronize the execution of Active User and User Handler from 
those used to synchronize Active User with Main Application (CCP) or User 
Handler with CCP. The synchronization of the Main Application program 
with all users was implemented through the same segment. 

c) Restrictions imposed on segment handling due to security access levels; 
segments with equal or greater access class must be passed between processes. 
The security access level is composed of two parts : Compromise (Observe) 
and Integrity (Modify). This research worked within Compromise 
constraints. Integrity involves levels in the system’s rings, 
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compartmentalization (audit, operator, programmer, etc.), and the concept of 
ring brackets. In order to keep the model simple, integrity was not 
considered. The execution of each primitive checks security constraints and if 
satisfied, the execution continues, otherwise the system aborts for security 
reasons. 

d) Main Application Program Segment Distribution. Figure 5.1 shows the LDT 
table including all segments needed by the seven processes (3 User handler 
processes. 3 Active User processes, and BDOS process). It also presents the 
segments used as mentors of other segments (31 and 44) and the segment 
used to synchronize the CCP (51). 



D. SYSGEN SUBMIT FILE 

Appendix F shows the Sysgen Submit File used to define the structure of 
the application programs developed in this research. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

1. System Operation 

The security check starts with the logon process. If the operator 
has a valid username and password that is recognized by the system, then the 
security level of this operator is adopted for the terminal, otherwise the system 
continues prompting for the username three more times. Failing a correct 
response, the system restarts the logon process. The main testing performed was 
the validation of the segments defined in the submit file. If they were "classified" 
the operator had to satisfy the security constraints in order to use this 
application. Otherwise, the system aborted the execution and prompted for a new 
logon operation. 

The application programs work according to the design, dynamically 
loading the user's security level in the "terminal logon" process. Access is limited 
to those users recognized by the system and restricted to the use of information 
based on the user’s access level. The interaction between Active User-CCP-BDOS 
is performed within security constraints (only compromise). The messages passed 
are "processed" by the CCP and results are returned to the user. 
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2 . 



Svstem Performance 



Because of the NPS system configuration, the performance of the 
application program is degradated for the following reasons : 

- Single processor emulating parallel processing 

- Secondary storage consisting of only floppy disks 

- Programmed I/O environment instead of interrupts 

B. RECOMMENDATIONS 

1. Hardware Improvements 

A system upgrade should be considered which at least addresses 
adding a hard disk to the present configuration. This would provide an 
improvement in the access time required to handle segments and decrease the 
response time in process creation. In addition, there would be a considerable 
reduction in the system development time, i.e., the time required to compile, link 
and sysgen, frequent operations in the development phase. 

Additionally, to take full advantage of the machine’s parallel 
processing abilities, more processors, two at least, should be added. Memory 
expansion would relax many restrictions currently imposed on process creation as 
utilized in this thesis work. 

2. Software Improvements 

The current system as delivered was incomplete with respect to the 
modules necessary to develop application programs in the Janus/ Ada language. 
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Software improvements, should include better documentation related to the 
system and debugging and programming tools for the application programmer. 

3. Future Research 



As a result of the research presented in this thesis, areas of related 
research should include the following : 

a. Directly Related to this Research 

(1) Inclusion of integrity access constraints (modify) into this current 
implementation. In this thesis, system integrity was considered at its 
minimum level in order to execute the application programs without 
limitations. Since this is a main issue with respect to the information 
security, a careful implementation should be developed working in this area. 

(2) Development of interrupt driven environment in the current design. 
The initial design using the BIOS module is an event driven system. This 
design approach was not used due to present hardware limitations as 
explained in Chapter IV. "Initial Design Constraints". 

(3) Addressing (solving) the issue of a restricted LDT size. This 
restriction is due to a limited number of application programs or application 
program complexity, since an upper bound of 27 segments are available for 
the user from the bounded LDT of 52 that a process can have. 

(4) Implementation of the "terminal logon" method. This function is 
simulated in the actual development through a module that loads the access 
class of a recognized user. A possible solution would be the conversion of 
those libraries provided by Gemini Computers Inc. from Pascal language into 
Ada language. 

b. Related to Secure Mass Storage System 

(1) Development of software "crossbar" in the Concentrator for 
integration of the Gemini computer into the Naval Postgraduate School 
Laboratory as a Secure Mass Storage System (S3). 

(2) Implementation of BDOS using a design for a one-level segmented 
secondary storage system and a large capacity hard disk (mass storage). 
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APPENDIX A - MAIN APPLICATION PROGRAM (CCP) 



This appendix presents the Main Application Program code, 
including the modules developed to handle the dynamic sharing of system 
resources. Instead of the present system consisting of several programs, each 
containing one module, all modules are grouped into one main program with the 
indicated modules separated by comments. This program is called "PRMAIN" 
and is listed below. 
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pragma rargecheck( cff ); pragma debug( off ); 
pragma ari th'cherk( off ); pragma enutab( off ); 

WITH agate, agatej , arl, alib, alibj, strlib, util, proce, 
files; 

PACKAGE B0E1 prmain IS 

USE agate, agatej, arl, alib, alibj, strlib, util, prcce, 
files; 



*** »*< %•/ **< *** «u «># 

_ m ^ ']'* #(* +f* *| ' »|< #(* »|» ^ +(% *p • f* »j» /j» +y /)■* #j» «>p 



Constants used by the urogram : 



STDIO W 
STDI0~R 
IO_FORT 
PREEOS 



--> assigns logical device 1 to write 
--> assigns logical device 0 to read 
--> main program uses port 0 of the RS-232 
— > process number for the BDOS 



STriC_W : CCMSTANT integer := l; 

S T E 1 0 _ R : CONSTANT integer : = 0; 

I0_P0RT : CONSTANT integer := 0; — pert zero for main 

NUMBER CE_ USERS : CONSTANT integer := 3; 

NUM3ER~0E_ FRO CESS : CONSTANT integer := 4; 

PRBEOS : CONSTANT integer := 4; 

N U M B ER _ PR 0 C E S S E S : CONSTANT integer := l: — * of childs 

MEM0RY_ AVAILABLE : CONSTANT integer := 130; 

SEGMENTS AVAILABLE : CONSTANT integer := 300; 



— Variables used by main program. 



w_class 
success 
mode 
m od e _ r 
def _ of f 
def _seg 
rl_def _ si ze 
sync hr seg 



acces s_cl ass ; 
integer ; 
at tech_struc t ; 
at tach_struct ; 
integer; 
ir t eger ; 

i n teger ; 
in teger ; 



ch_out : comard_line; 
ch_in : inpu t^m essage ; 
ch_resource : chi ld_ re source ; 
init : rl_process_def ; 
rd_str : string; 
class : access_class ; 

mentor : integer; 

entryx : integer; 

seg_mode : seg_acces s_type ; 

seg_number : irteger; 

CCP'BUSY : boolean; 



security asuects 
re sul t 
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ch_parameter : r l_parame te rs ! 
ch_param : rl_pararr! 
cfc’level : user_levei; 
ch_acce ss_level : level_rec crd ; 
ch~ch_user_synchrc : users _ac t ive ! 
ch_ch_evc_ val : integer? 

proces t integer! 
no_act ive_users : integer! 
evc_value : integer! 
evc_active : integer! 
active_user : integer! 
index : integer! 

— main 
BEGIN 

init := get _rl_def ( ) ! — ** this sentence is 

obligatory 



attach serial port for writing. 

This sentence is optional and is used to display messa- 
ges provided by the main application program on the 
screen . 



at tach_t ew ( IO_PORT, STDIO_k )! 

lib_set_bracket ( 1, 1, 1, init .resources .min_class )! 

%•* O # *1* %•* %*# %■* %•* O# O# %•* v# %'# %'# %•# %•* ««# 

^ ^ *1% *j% *|% >|% *!*•> * f % #1^ *|% *|* *|* *|* *|* *|* >1**1* #|* *|* *|* *1**1* #,* *|* *|* * t % * 4 * *|* *|-% *|* *|* *|* *|* *|* *|% *|* *|* *|* *|* 

— LOAD PARAMETERS MODULE 



This module assigns fixed parameters to each process 
that will be created. The parameters are mentor number 
entry number, segment number. They are used to create 
each segment needed by the process to be created 
(USER HANDLER). There is a group of these parameters for 
the stack, code, and data segments 



load_param ( ini t , ch_param)! 

load child actives array are additional pa ra meters 
used by the main application program to synchronize its 
operation with the ACTIVE USER processes 

load_c hi ld_active(ch_ch_user_ synchro)! 

— load access class that each process will have. In cur 
case all the processes will be multilevel. Minimum is 
unclassified and maximum is top-secret 
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load_access_class(init,ch_level); 
w class := ini t. resources, trex class* 



k 1 * *•» Or »'» « 



> »•* k 1 / k 1 / «■« « 



k<« k>. k'rk 1 ^ k*/ k'< k'# *•# kl 0 k'rf \t* O/ kV k 1 / kl^ k*rf k 1 / kV kV k'/k 1 # kl# k 1 / k 1 . k 1 * k 1 / k 1 / k'» k'i 

*)k / ( » <r,k / ( k /,k , t k /,k /,k / ( k »,k »|N /,k r ( k /,k i,S ^,k /|k *|-k /|S /,k ^|k » ( S /,k /| » «|k /,k <,k ^k #)' 



CREATE SEGMENTS MODULE 

This module creates the segments needed for the 
following : 

a. - Mentor cf the stack and data segments of each 

process and EDOS process. The standard elected 
was use entry 5 of the mentor inti al _segmer. t ( 2 ) 
"application mentor" and call this new segment 
31 in the LDT of the main 

b. - Syncbroni zat ion segment. Its mentor is the 

segment created in the previous step, entry 11 
of segment 31 was elected and this new segment 
was called 51 in the same LDT. The access class 
is TCP-SECRET 

ch_access_level := ch_level(l); 
mentor := init .initial_seg (2 ); 

entryx := 5* 

class .*= init .resources. min_class ; 

cr_segment( init ,mentor .entryx .class .success); 
if success /= 0 then 

put_succ( "success value 00 is" , success ,w_class ) ; 
pu t _ 1 n ( S TD 1 0_ W , w_c 1 a s s , " " ) ; 

END if; 



makekwcvn this segment with number 31 
seg_mode := r_w; 
seg_numter := 3 1 ; 

mk_ segment ( init .mentor .entryx , seg_ number, 
seg_m ode , succes s ) ; 
if success /= 0 then 

put_succ ( "success value 01 is " , succe ss , w_c la ss ) ; 
put_ln(STDIO_W ,w_cl ass,""); 

END if; 

create synchronization s egmer t (max access class) 

class := ch_acces s_l eve 1 .max ; 
mentor := 31 ; — segment 31 

entryx := 11; 
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cr_segment(init,mentcr,entryx, class, success) > 
if success /= 0 then 

put_succ( "success value 03 is " t success ,w_cla ss ) ; 
put_ln(5TBI0_W,w_ class,""); 

END if; 

makeknown this segment with number 51 

seg_mode := n_aJ 
seg_ number := 51 ; 

mk_segmen t ( ini t ,ment or ,ent ryx , seg_ number , 
s eg _mcde, success); 
if success /= 0 then 

put_ succ ( "success value t Z4 is ", success ,w_c la ss ) ; 
put_ln(STBIO_ , *',w_class,""); 

FND if; 

synchr_seg := seg_nurrhe r ; 

swapir this segments 

swapi n_ segment ( synch r_s eg , success 5 ; 

if success /= 0 then 

pu t_succ ( "success value it 05 is ", success ,w_cla ss } ; 
put i n ( s Trio v;,w_ciass," ") ; 

END if; 



»•# % ’ * V* * * 1 + %•# 

»,» <"1^ «’,> »l» 



»•» *•< O* o« 

/,* /|» 'l' # ( » 






j* ; Oj 






>|C 5 



• «|* « 



»'# »•# »•» O* V-* O* >1# vl* O* k< ( «'# J, 

»(» n* 'i' 't' <)' *i* »(» »,» /,» /(' *|% /|» 3 ( « «>,« 



V; > 1 f »'» « * %*« >'» *'« »'» ,V *iy 

'|' 't' # |' *,*• '| % *|* 'I* *|* *,« ^|» #,» *|* #|S 



CREATE PROCESS MODULE 

This module creates 4 processes 
(3 user handler and 1 EDOS) 

put_ln(STDIO_V, w_class , "PEG IN PROCESS CREATION") 

START CREATING EACH PROCESS IN THE SYSTEM 



process 


1 


====> 


TERMINAL 


HANDLER 


process 


r~^ 


= = = =:^> 


TERMINAL 


HANDLER 


process 


'X 


= = = => 


TERMINAL 


HANDLER 


process 


4 




EDO 5 HAND 


LER 



index : = 15 

while index < = NUMEFR_0F_PR0CE3S LOOP 
ch_rarameter := ch_param ( index ) ; 
all the processes will have multilevel access class 
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ch_access_level := ch_level(l)» 

lead the resources that the child will have 

memory — > 108 (converted to E24 format) 

segments > . 380 

processes 1 (max number of proc. that can create) 

ch_rescurre. memory := MEMORY _ AVAILABLE * 
ch_resource .segments := 3EGMENTS_AVAILAELE; 
ch_res ource .processes := NUMBER_PROCESSES i 

read_evc ( synchr_seg , evc_value, success )? 

cr_process (init t ch_ parameter ,ch_access_level , 

index,ch_resource,synchr_seg, success ) ? 

synchronize each time to let the new process displays 
its message (word USER) 

avai t ( synchr_seg , evc_value+l, success)* 
index := index + 1J 

end LOOP; 



J« »•< »'» »*» 

*js «|« »j» <,» » t » <,* 



»*# ■N*#’ **' * * O* v 1 * *1* *'» -** «'» »’< 

/|« *|*- #(» f » »(* »J* /|» <’(' <,» »)» »(» <,* / ( N 



%** *' * * ■* »'< »'* »'» »•» »'< »•» «'/ »'< »*/ «'/ *'» »'/ »'/ »'/ »'» »'< O* »’< »'< »'» *'< %•* »'< «l« «<« «l« «<• «<* »'< » 'y »'/ «.** %•/ %0 

/,« «|< /,* »|» *,* * ( % *j* /j* /|» *j% < ( » *,*« »j* »j» /,» *,> <,"« * j 1 * < ( » *(% /,» *,> /,» <j» /j* /,» /,» «|« *|*i *|* *j* *| * / ( % / ( * * 4 * /,» * ( % *,* *!* *j* * j> 

SYNCHRONIZATION PROCESS AND LOOP UNTIL NO USER IS 
ACTIVE 

This module executes the synchronization among 
processes, starting with the synchronization with the 
user's handler processes and then with the active user 
processes when these have leen activated 

ACTIVATE USER'S PROCESS 

This step stores the value of the eventcounts in the 
users' segments, the otject is to Knew which user 
sent the message 

index : = 1 ? 

while index <= NUMBER_OF_ USERS LOOP 

read_evc(ch_param( index) . seg_numher_stack:, 

ch_param ( index }. evn_ c cunt , success )» 
read_evc(ch_param(index).seg_numher_data, 

ch_param( index) .evn_ccunt_data,success ) 5 
advance(ch_ pa ram (index ) . seg_oumber_ s tack, success ) * 
index := index + 1» 



end LOOP; 



LOOP UNTIL NO USER IS ACTIVE 
This loop is the main process's module in the whole 
system because will he in execution until all the users 
finish their jobs (enter the word "bye") 

CCP_BUSY := FALSE; 
no_active_ users := 0; 

while no_ac ti ve_use rs < NUMEIR_GE_USERS LOOP 

if C CF_EUS Y then 

C CP_BUS Y := FALSE? 
else 

read_evc ( synch r_ seg , evc_value, success ); 
awai t ( synchr_seg , evc_value+l, success ); 

ENE if; 

active_user := 0; 
index := l; 

determine the user that sent the message comparing the 
event count value, different value means that user was 

while index <= N UMBER _OF_ USERS LOOP 

read _ eve (ch_param( index ) . seg number _da ta , 
evc_active, success "5; 
if (evc_active > 

ch_pararr (index ) ,evn_count_data ) then 
active_user := index; 
ch_par am (index) .evn_ccunt_data : = 

evc_acti ve; 

index := N UMBER _OF_ USERS + l; 

else 

index := index + i; 

END if; 

ENE loop; 

checks if the activated process came from an user 
handler or an active user. If came from the active 
user it means that the variable "acti ve_user" is in 0, 
otherwise it means that the communication is between 
a user handler process and the main program (CCP) 

if active_user /= 0 then 

def_seg := 1 i b_mk_sel ( Id t_ table , 

ch_param(active_user ) . seg_ number _d ata ) ; 
def _ of f := 0; 

rl_def_size := input_message 'SI ZE/8 ; 
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move_bytes(def_seg,def_off,get_ss( ) , 

ch_in 'ADDRESS , rl_aef_size) ; 
ch_paramet er := ch_param(active_user) ; 
if ch_ch^use r_ synchro ( ac ti ve_user ) .act ive then 
ch ch user_synchro (active user). active := 

false; 

terminat e_ synch r_s eg ( i ni t t c h_ parameter , 

ch_in. in put_class, success ) ; 
if success /= (> 0 then 

put_succ(" terminate ’* .success, v_class)» 
put_ln ( STDIC_'* , w_class, "") ; 
end if; 

if ch_in . i nput_ cne = "bye" then 

n o_a ct i ve_users : = no_acti ve_users + l; 

else 

ad va nee ( 

ch_param(acT.ive_user).seg_numter_steck 
success ) ; 

END if; 

else 

if ch_in . input _ cne /= "lye" then 

make_kn ow_sy rc ( in it t ch_ parameter . 
ch_in.input_class , aotive_user, 
ch_ch_user_ synchro, success) ; 
ch_ch_user_synchro( active_user) .active : 

true; 

advan ce ( 

ch_param( act ive_user).s eg _n urn ter_ stack 
success ) 5 

el se 

no_ac tive_users ;= no_ac ti ve_users + 15 
END if; 

END if; 

ELSE 

index := l; 

while index <= NUMEER_OF_USE RS LOOP 

if ch_ch_user_synchro ( index ). active then 

r ead_evc ( ch_ch_user_ synchro ( ind ex ) . seg_da ta , 
ch_ch_evc_val , success); 
if ch _ch_evc _ va 1 > 

ch_ch_user_ synchro (index). eve _data then 
active_user := index; 

ch_ch_user_synchro (index) .evc_data := 
ch_ch_ evc_ val ; 

index := NUMBER _ OF _U SIRS + 15 
END if; 
fnd if; 

index := index + 15 
END loop; 

if active user = 0 then 
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put In ( STD IO_W ,w_cl ass , "active user error")’ 
END ie; 

def_seg := lib_mk_sel ( ldt _ table , 

ch_ch_usef_ synchro (active_user) . seg_data ) 
def _ cf f := e; 

rl_def_size := input_message '3IZE/S; 
move_tytes(def_seg,def_cff,get_ss(), 

ch_i n ' ADDRESS , rl_def_size); 

convert(ch_in,w_class,ch_cut)» 

pass the segment to prhdos process 

def_seg := li b_mk_sel (ldt_table , 

ch_pa ram ( PREDOS ) . seg_number_dat a ) *’ 
def _ of f : = 0 » 

rl_def_size := comar.d_lir. e'SIZE/8; 
mcve_tytes(get_ss( ) , ch_ ou t ' ADDRESS , def _s eg , 
de f_ of f , ri_d ef _s i ze )? 

ACTIVATE EDO 5 PROCESS 



ad vance ( ch_oaran( PRBDOS ) . seg_ nun ber_ stack , 
success ); 

read _evc ( synchr _ seg , evc_value f success)* 
awai t ( sy rchr_seg , evc_value j -l f success )* 



RECEIVED MESSAGE WITH RESULT HAS TO EE PASSED TO THE 
USER 

def_seg := lib_mk_sel ( Id t table, 

ch_param ( FREDOS") . seg_numte r_da ta ) ; 
def _ of f := O * 

rl_def_size := ccnand_line 'SIZE/8 > 
move_bytes(d.ef_seg,def_cff,get_ss{ ) , 

ch_ out ' ADDRESS , rl_def_size)J 

assemble user message with the result 

ch_in. irput_result := ch_out .result » 



pass the segment to user process 

def_seg := 1 ib_mk_sel ( Id t _table , 

ch_ch_user_ synchro ( active _ user ) . seg_data ) ; 
def_cff := 0*» 

rl_def_size := inpu t_message '3IZE/8 » 



69 



move _ by tes( ge t_ ss ( ) , ch_ in ' A CD?. ESS , def _seg , 
def cf f ,rl _def _ size ); 



advance the process that executes the command 

ad van ce( ch_ch_user_sy nchro ( act iv e_us er).seg_ stack, 

success ); 



END if; 

active_user := 0 ; 
index := 1? 

determine if while CCF was busy executing the previous 
commands, some user handlercr active user sent 
a message 

USER HANDLER 

determine the user that sent the message comparing the 
pve~t count value, different value means that user was 

while index <= NUMBER_CE_ USERS LOOP 

read_evc’(ch_param ( index ) . seg number_data , 
evc_active, success 7? 
if 'evc_active > 

ch_param ( i r.aex ) . e vn _ c oun t _d a t a ) then 
CCP_BUSY := TRUE; 
active_user := index; 
index := NUMBER _OF_U SEES + i; 

else 

index := index + 1 ; 

EN D I i » 

FND loop; 

ACTIVE USER 

determine the user that sent the message comparing the 
event count value, different value means that user was 

index := l; 

if active_user = 0 then 

while index <= Nl T M B ER _ 0 E _ U 5 ER S LOOP 

if ch_ch_user_synchro( index ) .acti ve then 

read_evc(ch_ch_user_synchro (index) .seg_data , 
ch_ch_evc_ val , success); 
if ch_ch_evc_val t 

ch_ch use r_ sync hr o( index ) .evc_data then 

CC?_EUSY := TRUE; 

index := NUMBER _OF_ USERS + 1J 

end if; 

END if; 
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index := index + l; 
END icof; 

END if; 
end LOOP; 



ACTIVATE EDOS AGAIN AND VAIT UNTIL CHILD DELETE ITSEF 



ch_out . command := "tye ; 

def_seg := li t_mk_sel ( ldt_tatle , 

ch_param( PR3D0S ) .seg_numter_data); 
def _ cf f := e; 

rl_def_size := c omand_ line ' S IZF/8; 

move_ ty tes (ge t_ss ( ) ,ch_out'ADD?.ESS,def_seg,def_cff, 
rl_def_si ze ) ; 

ad va nee ( ch_pa ram ( PR EDO 5 ) . seg_ rum ter_ s tack , 
success ); 

read_evc ( synchr_seg , evc_value, success); 
awai t ( sy achr_seg , evr _value-*-l , success ); 
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BEGIN DELETING FHOCESESS MODULE 

This module eliminates the user's handler processes create 
to support the active user processes, since each 
process required of a specific num ter cf segments that 
were created in the C RE ATI_PROCES 5 module , these will 
te terminated and deleted in this step 

prcces : - ?' ; 

while prores < NUMEER_OF_PROCESS LOOP 
child_delete (proces, success ); 

put_succ( "child deleted " ; success, w_class ); 
put_lr( S T D 1 0 _ , w_class, " ‘ ) ; 

termirate_segment( ch_param. ( prcces+1) . seg_number^stack , 

success }; 

term in a te_ segmen t(ch_pararr(proces + l).seg_nurrter_data, 

success } ; 

terminate_ segmer t(ch_param(proces+l).seg_nurter_code, 

success ) ; 

delete_segnert(ch_param(proces- u l).mertor_stack, 

proces+1 , success ); — delete entries 

delete_segrrent(ch_param(proces + l) .mentor_data , 

pr oces +5 , success ) ; — delete entries data 
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del e t e_ s e?nen t (ch_param(proces+l).mentor_code, 

proces+6 , success ) ; — delete entries code 

proces := proces + 1 ! 

end LOOP; 



»*» s** »•« %ft J/ *•/ »'< s** v*# »•» sl* %*» s<* s** «l« »•» *•# s** sl* >*» »•# O/ »•* »l< »•< »•» »l» »•* d 1 / »•» «<< % l/ .l< v l< V* J« <.!> 
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TERMINATE SEGMENTS AND DELETE SEGMENT MODULES 

These modules will terminate and delete the segments 
created previously to hold the mentor segment used to 
create the user's stack segments ar.d the user's data 
segments, and the synchronization segment to 
establish c ommun i ca t i on among processes. 



terminate and delete synchronization segmen t 

teririnate_segment (51 , success ) » — segment 51 

del et e_segment (31 ,11 .success ) » — entry 11 

terminate and delete mentor segment 

terminate_segment( 31 , success ) » — segment 31 

del ete_segrren t ( i ni t . i ni t ial _seg( 2 ) , 5, success )l 



J . sl* »*# »l# «l« «l< \ I- »•> »*» J . v*« «.•/ »•* *•/ «l« »•* »•* <iO « ( « »*/ »>/ »•» »•» si/ s 1 / si/ sl/ s 1 / s 1 / s'/ s 1 / s 1 / s>/ s’* s'* s'* s'/ s'/ si/ s'* s'* s'/ s'/ S 1 / s'/ s'/ 

<|S /|S -|S /jS *|S /|. /|S *|% /j. /j» *|S / ( s *fS / ( s / ( S /p #|% /|S /|S /,s /|S /|S *|S *|S /jS /|S /p /|S *jS /jS / S /|S / t s /,S /,s *|% /p (| S *|S> /,s /p /|S /,s «|% /|S / ( S /|S *|% *|% / ( s /|S /p *|% *|% / p 
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END PROCESS 

put_ln( STDI0_v; , v_class, 



GOOD BYE 



); 



Infinite loop to prevent trap. Could also await an 

eventcount . 

success : = 0 ; 
while success = 0 LOOP 
success := Z; 

END loop; 



prma i n ; 
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APPENDIX B - USER HANDLER APPLICATION PROGRAM 



This appendix lists the User Handler Application Program 
code. Only one program is provided since the three different programs, one for 
each different user, differ only in the port used on the RS-232 board, which is 
indicated below : 

Port 6 User 1 

Port 5 User 2 

Port 3 User 3 

The programs are called PUSERl, PUSER2, and PUSER3. 
The program listing for user 1 is detailed next. 
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pragma rangecheck( of f ); pragma debug ( of f ); pragma 
arithctiecA(cff); pragma enumtab ( of f ) ; 

VITH agate, agatej, arl, alib, alibj, strlit, files, util, 
nrcce; 

PACKAGE POET puserl IS 

USE agate, agatej, arl, alib , alitj, strlit, files, util, 
rr oce ; 

«>« «'< *•» >■# *l» »'/ »'» »'/ *•» »'< *•» »'* »•» »'/ *'* >■*»•* V* »'/ ,',«<« *’# 

— — /|« /|> *,> ,,, / 1*« ,|t /|« #|» »,> /|* /,* /|* »|> /|> »)' *!» »,» »|» /|» #|* /|* /(* #|» /,* /|> /|« /|* #|* /|» # |> #|% r ( i ,|» ,|, /,> /|< 



— — 


C on s tan t s 


used 


by the 


prograr 






— 


STD 10 


/ 


assigns 


logical 


devi ce 


1 to write 


— 


STDIO'R 


— > 


assigns 


logical 


device 


0 to read 


— 


I 0_P0RT 


— > 


assigns 


the ports according with the 


— 






follow 


detail : 






— 








puserl 


--> 


port 6 


— 








pu se r2 


— > 


port 6 


— 








puser2 




port 2 


— 


PROCESS 


--> 


assigns 


prcess 


number 


1,2,2 for puser 



puser2 and puserZ respectively 



STD io v; 


: CONSTANT 


integer 


:= i; 


STD 10 R 


: CONSTANT 


integer 


: = 0; 


10 PORT 


: CONSTANT 


integer 


:= 6; 


PROCESS 


: CONSTANT 


integer 


:= i; 



MEMORY AVAILABLE : CONSTANT integer := 60; 
SEGMENT S_AVA ILAEI.E : CONSTANT integer := 100; 
NUMBER PROCESSES : CONSTANT integer := 0; 



Variables used by the program 



: ac c es s_cl ass ; 
: integer; 
input_message; 



w_clas s 
success 
c h _ i n i 

data_def _size : 

def _ of f : 

d e f _ s e g 

ch_evc_val : 

evc_ch_val 
rd_str : 

username : 

password : 

ch_class : 

ch_resource : 

eco : 

enc_prog : 

ch access level 



integer ; 
integer; 
integer; 
i r. teger ; 
integer; 
string; 
string(8 ) ; 
string(£ ); 
acce ss_c lass; 
child_resource ; 
boolean; 
boolean; 

: level record; 



74 



ch_level 
ent ryx 
men t or 



user_level ? 
integer; 
i n teger ; 



seg_mode : seg_acce ss _ type 5 

seg_r.urter : integer; 
ch_parameters : r l_parameters ; 
in it : rlprocess d e ? ; 



MAIN 



Begin 

init := ge t_ rl _def ( ) ; 



>;c 



J 1 / j'j *'/ J 1 # s'/s 1 / 



»V 

't' "i' *r 



this sentence is obligatory 



— ATTACH TERMINAL MODULE 



This nodule attaches port I to its process in order to 
use it in I/O operations 
attach terriral as write device 

attach _tew( IO_PORT , STDIO_V:); 

w_class := i ni t . resources ,rrax_cl ass ; 

attach terminal as a read device 

ettech_ter( IC_PORT , STDIO_P. ); 

indicates that was activated oh 

put_ln ( STD IC_ w , w_clas s , "U S E R " ) ; 

synchronize with the main application (CCP) to indicate 
that it was created ok and allow continued execution 
usirg the await operator. It means that the process will 
wait until the main application returns control to this 
process 



advarce( i ni t . i ni ti al_seg ( 2 ) , success ); 

read_evc ( ini t . i ni t ial _s eg ( 0 ) f evc_c h_val, success ); 

a wa i t ( in i t . ini t ial _seg( 0 ) , evc_ch_val+l , success ); 



»'• 

_ _ — - *(» /|* f 
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LOAD PARAMETERS MODULE 



This module assigns parameters to the process that it 
will create. These parameters are rentor number, entry 
number, and segment number, used cy stack, code and data 
segments needed by the urocess to be created 
(ACTIVE USER) 

load_paraml- ini t,ch_para meters); 
lcad_access_class( ini t , ch_l evel ) ; 

end_prog := false; 
while net end_prcg LOOP 



LOOF MODULE 

This module executes several operations until the opera- 
tor enters the word "bye”. This means that the users work 
is finished a-nd termiantes this process execution. The 
steps considered are : 

a. - Clearance identification 

USER NAME and PASSWORD (login process) 

b. - Create and nakeknevn mentor and synchronization 

segments 

c. - Load the child's resources (this will be 

subtracted from the parent resources) 

d. - Create child process (ACTIVE USER) single level 

e. - Detach the device used for I/O, it will be used 

by child 

f. - Synchronize with the child created to indicates 

what was created (USER CHILD) 

g. - Synchronize with main appl ication program ( CC P ) to 

indicate that an ACTIVE USER was created. In turn 
CCP will makeknown the segments that are synchro- 
nized with ACTIVE USER (4b, 46 for userl; 

47,48 for user2, 49,50 for user3) 

h. - Synchronize main with active user and wait until 

the active user finishes his job 

i. - When ACTIVE USER terminates his job the user 

handler recovers the resources assigned to his 
child and terminates and deletes the segments 
created to be mentor and synchronization, plus all 
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the segments needed to create the child 
(loaded in step t) 

j.- Synchronize with CCP to indicate that ACTIVE USER 
is not longer active 
END LOOP 

clearance identification 

tlk_scr(STDIO W , w_cl as s , "" ) » 
put_str(STBIO~W,w_class /'USERNAKE ") ; 
eco := true? 
username := " 

username := ge t_ i npu t ( ec o , w_c lass ) ; 

pu t _ln ( STD IC_W A w_cla ss , " " ) ; — put cursor in next line 

if username = ’ bye" then 
end_prog := TRUE? 

pise 

put _s tr (STDIOJtf, v_c lass /’PASSWORD " ) ? 
eco : = false? 
password := 

password := get_input ( ecc , w_cl ass) ; 
put_ln(STPIO_W,w_class,"”) ? 

lock_for_level(u serna me, password, ch_level,ch_class); 

create mentor to the child process 

ch_access_level := ch_level(4); — min access class 
mentor := init .initial_seg(l ) ; 
entryx := 35 

nh_class := ch_access_level .min ? 
create the mentor segment 

cr_segment(init .mentor , entry x,ch_class .success ) » 
if success /= 0 then 

put succ( "success value 04 is ", success ,w_c lass ) ; 
nut"ln( STDIO_W,w_class ); 

END if; 

makekrcwn this segment - 

seg_mode := r_w; 
s eg _ number := 31 ; 

mk_segment(init, mentor, entryx, seg_ number , seg_m ode , 

success ) ; 

if success /= 0 then 

put_ succ (" success value 04 is ", success , w_c la ss ) ; 
put_ln(STDIO W,v class,""); 

END if; 

ch_access_level.min : = ch_access_level.max; 
single level 
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load the resources that the child will have 

memory — > 60 ( format B24) 

segments — > 100 
processes -> 0; 



ch_res ource .memory := KEf-'!ORY_AVAILABLE> 
ch_resource .segments := SEC*h’ENTS_AVAILAELE; 
ch'resource .processes := NUMBER_PROCESSES5 



SYNCHRONIZATION : code segment will he used to 

synchr. parent and its child, tut 
init ial_seg (2 ) is used to synchr. 
child with main application program 

cr_ proc ess ( init, ch_parareters,ch_access_level, 
process, ch_resource,ir. it .initial_seg(2) , success) ; 
if success 7= 0 then 

pu t_ sue c ( ’’ sue ce s s valuers is ", success ,w_class ) ; 
pu t_ In ( STDI0_W , w_cla ss , " ” ) ; 

ENE if; 

read_evc(ch_parameters.seg_number_code, 
ch evc_val .success )» 



detach_device(S?DIO_V? f success ) 5 
detach_device(STDIO_R , success) 5 

await(ch_parameters.seg_numter_code,ch_evc_val+l, 

success ) ; 

synchronize with main application program to create 
segments to hold stack and data (will he used as synchr. 
segments with the new process) 



def_seg := li t_mk_se 1 ( Id t_ ta hie , in i t . in i t ial seg(3)); 
def _of f := 0; 

ch_ in . inpu t_ one := username; 

ch_in .input_result := 

ch_in . input_class := w_class; 

d a ta_def _si ze := (input_message'SIZE/8) ; 

move_hy t es (get_ss ( ) , chi n 'ADDRESS , def_seg, def_off, 

da ta_def _ si ze); 

synchronization process 

ad vance( ini t . i ni t ial _seg( 3 ) , success ); 
advancefini t . ini tial _seg(2 ) , success ); 
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r ead_evc ( in i t . in it i al_ seg( 0 ) , evc_ch_val f success ); 

await( init . ini t ia 1 _ seg (C ) , evc_ch_val +1 , success )» 

read_evc(ch_parameters. seg_i?um ter_c ode , 
ch_e vc _val , success )» 

advance (ch_para me ters.se^_nurrter_stack, success ) *» 

will await until child self delete 

await (ch_ pa ramet er s . seg_numher _ c ode t c'n_evc_v al +1 , 

success ) » 



if success /= 0 then 

put_succ( "success value 10. is " , sue cess , w_c la s s ) » 
put~ln( STDIO_W t w_class , ”” ); 

ENE if; 

attach I/C terminals again and delete segments created 
created for the child process 

at tach_ tew ( I0_P0RT , STT IO_W ) ; 
attach_tpr( IO_PORT t STDI0_R); 

delete segments 

t ermina te_segmen t ( ch_ pa ra meters. seg_numher_stack t 

success ) ; 

t erm ina te_segmen t( ch_parameters.seg_numher_code, 

sue ces s ) » 

t ermina te_ segmen t(ch_ para meters. seg_numfcer_data, 

success ) ; 

delete_se gr, ent(31 t ch_para me ters.entry_stack, success); 
d el e te_ segment (21,ch_parameters.er.try_data,success N ; 

t erm ina t e_ segmen t ( 31 , success); -- terminate mentcr 
d el et e_ segmen t (ini t .initial_seg(l) ,3, success ) ; 
child_delete( PROCESS-1 .success ) ; 

communicate with main application program to delete the 
segments to held stack and data that were created to 
synchronize main with child 



def_seg := 1 i t_mk_sel ( Id t_ tail e t ini t . i ni t ial _seg( 3 ) ) ; 
def _ off := 0; 

ch_in . input _ one := username; 
ch_ir. .input_result := ? 

c h _in . i npu t_c la s s := w_class; 
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data_def _si ze := ( input_message 'S IZE/8 ) 

trove_t> tes (get_ss( ) , ch_in 'ADDRESS ,def_seg, def_cff, 

da ta_def _si ze ) ; 

synchronization process , the control will return to 
main application program CC? 

advanced init . ini tial_seg(3 ) , success ); 
advance( ini t . ini tial_seg( 2 ) , success ); 
read_evc( init . init ial_seg(0 ) , evc_ch_val , success }; 
await( ini t . initial_seg^0 ) , evc_ch_ val + 1 f success ); 

end if; 



end LOOP: 

— synchronize with main application program to tell that 
the user no longer will use the terminal 

def_seg := 1 i t_mk_s el ( la t _ ta hi e , i ni t . i ni t ia 1 _seg( 3 ; ) ; 
c e f _ o f f := 0; 

ch_ i n . i n pu t_ one := username; 

ch_in.input_result := ’; 

ch_ in . input_ clas s := w_class; 

d at a_def _s i ze := (intiut_message 'SIZE /8 ) ; 

mcve_ty tes (get_s s( ) , ch_in 'ADDRESS ,def_seg , def'_off, 

da ta_def _ si ze ) ; 

detach_aevice( STDIO_R, success); 
detach_device( STBI0_W, success ); 
advance ( ini t . initial_seg(3) , success ); 
self_deiete( i"i t . ini tial_seg( 2 ), success ); 
if success /= 0 then 

at tach_tew ( I0_?ORT , STDIO_V ); 

pu t _ succ ( " succe s so r is ”, success, w_class); 

END if; 

END puseri; 
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APPENDIX C - ACTIVE USER APPLICATION PROGRAM 



This appendix lists the Active User Application Program 
code. Only one program is provided since the three different programs, one for 
each different user, differ only in the port used on the RS-232 board, which is 
indicated below : 

Port 6 User 1 

Port 5 User 2 

Port 3 User 3 

The programs are called PRCHLl. PRCHL2. and PRCHL3. 
The program listing for user 1 is detailed next. 



81 



pragma rangecheck ( of f ); pragma detug(off); 
pragma ar i thcheck ( of f ); pragma enumtat( of f ) ; 

WITH agate, agatej, arl, alit, alitj, strlit, files, util; 
PACKAGE BODY prchll IS 

USB agate, agatej, arl, alit, alitj, strlit, files, util; 



Constants used ty the urogram 



— 


STDIO W 


— > 


assigns logical 


device 1 to write 


— 


STDIO R 


— > 


assigns logical 


devic 


e 0 to read 


— 


10 FORT 


— > 


assigns the ports acc 


orcing with the 


— 






following detail 


• 




— 






puserl 


— > 


port 5 


— 






puser2 


\ 

*" ™ / 


port 5 


— 






puserZ- 


— > 


port 3 



STIICJ? 
STBIO_H 
10 PORT 



COM ST ANT integer := 1J 
CONSTANT integer : = 0 5 
CONSTANT integer := 6 5 



varieties used ty the program 

w_class : access_class ; 
success ; integer; 
oh_in : ir.put_mess age; 



data_def _si ze 
def _ of f 
def _seg 
evc_ch_val 
rd _ s tr 
eco 

end pr eg 



integer; 
integer; 
integer; 
integer ; 
s t ring; 
toolean ; 
toolean ; 



in it : rl_process_def; 

— MA I N 
Begin 

init := get_rl_def ( ) ; — this sentence is obligatory 

V# O* %}+ O/ J# v 1 / *** ' 

M| ^ #|% *,W|* /,' /|% #!«■ *4* # 

— ATTACH TERMINAL MODULE 

-- This module attaches port X to this process in order to 



82 



use it in I/O operations, the device will have the sarre 
clearance that the process has 

w_class := ini t . resou rces .max_cla ss ; 

attach terminals (read and write) 

a ttach _ te r ( IO_PORT, STDIO_R ); 

a ttach_ tew ( IO_PORT, STDIO_W )J 

put_ln (STDIO_V ,w_class, "USER CHILD ” ) ; 

Syncrcnize with USER HANDLER to indicate that it was 
created ok and let him continue his execution using the 
advance, and await operator (advance User Handler 
evert count to continue, and await to stop its process 
and returns the control 



advance (in it. in itial_seg(l), success); 
read_evc(init.initial_seg(0) ,evo_ch_val , success ) ; 
awai t ( ini t . ini tial_seg ( 0 ) ,evc_ch_val j -l , success ) ; 



/|C »,C m 



>|c ;',c 
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LOOF MODULE 

This module executes several operations until the 
operator enters the word "tye" that means work is done 
The steps considered are : 

a. - Fut prompt ( " * ) " ) indicating that is ready to 

accept ACTIVE USER input messages 

b. - Get the user's input message 

c. - Load input message entered by the user into 

segment data used to pass the information 

d. - Synchronize with main application program CCP 

waiting for the answer to the message sent 

e. - Display the result of the message after it was 

processed by CCF 

TND LOOF 

eco := TRUE; 
end_prog := false; 
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while net end_prcg LOOP 



get input messages from the terminal 
rd str := " ”; 



put_str (STL IO_W,w_c lass,”* ) " ) ; 
rd_str := get_input(eco,w_class); 

put_ln( STLIO_W t w_class, ””)» — put the cursor in 

the next line 

def_seg := lib_mk sel ( Id t_table , i ni t . ini tial _seg (3 ) ) ; 
def _ of f := 0; 

ch_i n . i npu t_ one := rd_str» 
ch_ i n . i npu t_resul t := 
ch_in . inpu t_class := w_class; 
data_def _size := (input_message 'SIZE/6) ; 

mo ve_by tes ( ge t_ ss ( ) , ch_in 'ADDRESS , def_seg, def_off, 
da ta_def size); 

if ((ra_str = "bye"] or (success /= ft) ) then 
end_prog := true; 
e 1 se 

begin the synchronization process 



advance(iait.initial_seg(3), success ); 
advan ce ( ini t . ini tial_seg( 2 ) , success ); 

read_evc ( i ni t . ini tial_seg(0 ) , evc_ch_val, success }; 

aweit( init . init ial_seg(0 ) , evc_ch_val+l t success ); 

display the answer's message that was transmitted by CCP 

def_seg := lib_mk_sel ( ldt_ table , in i t . ini tial_seg(3 )) ; 
def _of f := ?; 

data_def _si ze := ( in pu t _ me ssage ' S IZI/8 ) ; 
m ove_by tes (def _s eg , def _cf f t ge t_ ss ( ) , ch_in 'ADDRESS , 
data_def _si ze ) ; 

put_ln( STD I0_V , w_class, ch_in.input_resu.lt ); 



end if; 



end LOOP; 



O# O# %*+ O# O# O* O* o# o# 

/jS ^|> 



o# o# >•# 
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* # * * * :;c 3): ;;c >;c 5jc 5|; ;|c >;s ? |c 3|c 3;: }' ( s 3 j; 3 ^ 3;c >;c 3j: 3|c 3|C 3JC 3li 3|c sjc 3 |; 5 ; : 



* h 1 # *■* *■* %U h 1 / H 



— DETACH TERMINAL MODULE 



This module returns the device's control to the user 
— handler 

detach_device ( STDIO_R, success)? 
detach_de vice ( STDIO_W t success ); 



O# *•* O# *** H 1 / *■* *1* *•* « ( # 

*1* 'I'* *|* * ( * *|*> r 4 ^ #|% <?|* 






O# %•# 0*0* v* 

*!* *j* *|* *j* *|* *|* *|* >!* 



O* *•* *•* *** *■* *■* %V %i# *■* *i* *•* *•* 
*|* *|* *,* *|* *,**|* *|^ 



*•* O* s 1 * *i* *V *•* *•* *** >■* < 

|H * # * *|* *,* *,* *|* *,* *,* *j* >>* 



*»* *‘* *•* 
'I' 



Of O* *** 0**1* * l* * 1 ** 1 * *•* * ( #«i# %i* *i* \l# ****** o* *1* 

*1 # r *§* ^i' *|^ *p *|^ *j* ✓,* *|* *|* 



O* *1* si** 1 * % 1 * >1* *1* 

*1* *,* *|* * t * *!* >j* 



— SELE DELETE MODULE 



— This module terminates the child process (ACTIVE USER) 
an-d advances the eventcount cf the segment indicated. 

In this case it is the segment used to synchronize with 

— his parent (user handler) 

self_delete( ir.it . ini tial_seg( 1 }, success ); 
if success /= 0 then 

attach_tew( IC_PORT , STDIO_V< ); 

put succ( "successor is '' f success, w_class); 

END if; 



iND prchli; 
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APPENDIX D - PRBDOS APPLICATION PROGRAM 



This appendix presents the application program used to 
simulate the behavior of the BDOS operating system. Because of time constraints 
this program only has code that shows the process that should be performed when 
BDOS in invoked, simulating the result in order to pass it to the CCP process. 
This program is called PRBDOS, and its listing is next. 
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pragma rangecheck( of f ) ; pragma detug(of'f); 
pragma arithcheck( of f ) Jpragma enumtat( of f ) ; 



WITH agate, aga te j , 
PACKAGE BODY prtdos 
USB agate, agatej, 



arl, alit, alitj, strlit, files, util; 
IS 

arl, alit, alitj, strlit, files, util? 



O* s 1 / sU 

>|N /|N /|N 



H 1 / O# «JU O/ vl / 1 

*** *y* or* o x ^i n /p #p /p 



This program only simulates the tehavior of the 3DCS 
work, in order to handle “disk files" 



* O* %*/ %'/ O# s'*» %*# %•/ %'/ **i O# %V %'# %•/ %'/ \V %•/ «i# % 

>> /p /p /p /p -»p /p V / P ^p ^p ^p^p ^p/p ^p -»p ^p^ -»p >p /p <»p /p /p /p /p /p ^p ^ 



con stants 



STDIO’ V 


: CONSTANT 


integer 


:= i; 


STDIO R 


: CONSTANT 


integer 


:= 0 ; 


» — < 

0 

1 

•x> 

o 

w 

HJ 


: CONSTANT 


int eger 


:= 3? 



— MAIN 

w_class : access_class ; 
success : integer; 
data_def _size : integer; 

def_cff : integer; 

def_seg : integer? 

evc_ch_val : integer; 

ch c cmm : com and line; 



end_pr og 
— f i le_da ta 
— s eg_head 
— seg data 



boolean ; 

: files_ 
: segment 
t segment 



in it 



rl _pr oce s s_def 



data; 
_header; 
data ; 



Begin 

in it := get_rl_def(); 



# * * * * ❖ * * ❖ # ❖ # * 'A' * * t~ ❖ ❖ * * ❖ * # # * * * # ❖ ❖ # * # * * * * * # ^ * * * # * ;|c -.Jc * 



attach terminal as write device 

w_class := in i t .res ources .max_cl ass » 
— a t tact tew ( 10 FORT, STDIO V); 



%'/ O* ,1/ O# s'« V« ,1/ 

*,» /,» <,% «|» »,* *)• /,« < ( s 



3'C )'* j*j j'j 



/,% ^|* #,* 



3 '* »•*%' <*»•<* *'* ••<< O* O* %'<» %** «»•<* O* O s<< N l* «,•«*»'« O* 

i s *,* *(' 'i' 'i' * 1 ' 'i' /,» #|» /|» 3,« 3,% < t ,3|S 3,* 



initialize directory 
put_ln(STDI0_W , w_class, "B D 0 S 



8 ? 



JU J# U# %i# WU «A# %•# JU %V %U V* %•* %•# %•# V# %‘f %•# O# %*# ^ V # %<# %i^ %i* %V «•>* vO o# %V 

^ ^ ^ *1% *p ^1% *p ^|% *|* ^|% *p *p >|^ #p *p ^f» *p *p ^|% *p *p >p *p *p *p *p >p #P ^ *p *p *p *p *p ip *p #|% *p *p *P #|% *p #p *p *p *p 

Synchronization with CCP to tell that it was created 
without trouble 

begin the synchronization process 

advance ( init . ini tial_seg(2 ) , success ); 
read_evc(init.initial_seg(0) ,e vc_ch_va 1 , succes s )» 
awsit( init . initial_seg(0 ) ,evc_ch_val + i .success ); 
— PROGRAM WAITS UNTIL THE CONTROL IS PASSFB FROM CCP 

OU %}+ s*# *4f «A# v*# O# ^ «J# J# ^1# «U %U %U J/ 

«M *p >p *p *p ^ *p #p *p *p *p >p ^ ^p #p *P >|% ^p #*p *jW **p #p *p ^p ^p *p 0»p #p *p ^p Jp ^p ^p ^p >p ^ *p ^p *p *p ^p *p ^p *p ^p *p #p #p 



end pros := false; 



*, i * vl* *' 1 * X sV 0> X Jf %V x^# vi# X X %*# *1* hC *** %•# \l# x 

# t % #p *p *p ^ j»p ^p o' o % *p 'i' *p t *p *p *p *p ^p o' «*p o' # r o' o' *p *p *p *p*p *i' 



j# j# %•# %•# 



Begin loop until CCP sends "bye 



while not er.c_prog LOOP 

get command line passed by CCP 

def_seg := 1 i b>_mk_sel ( Id t_table , i r.i t . in it ial _seg (3 ) ) ; 
d ef _ of f := 0; 

data_def _si ze := ( c orrand_ line 'SIZE/S ) ; 

move_bytes (def_seg.de f_off,get_ss( ) , ch_ccmm 'ADDRESS , 
deta_def _si ze ) ; 

put_ln( STDIO_W,w_class , ch_c orrrr .command ) ; 

if ( ch_c omrr .c omrrand /= "bve ”) then 

IF ch_comm . command = "create " TEFN 
ch comm. result := “file created"; 

create_f ile( ) ; 

FISIF ch_comm. command^ "delete ".then 
ch_comm. resu It := "file deleted"; 

del ete_f ile( ) ; 

FLSIF ch_comm.c ommand.= "renarre ".then 
ch comm. re suit := "file renamed"; 
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rename f i 1 e( ) ; 



ELSE 

ch comm . result := "mess, processed 
END if; 



load the result to pass it to the parent process 

def_seg := lib_mk sel (ldt_table , ini t .initial_seg(3) ) ; 
def _ of f := 0; 

da ta_def _ si ze := ( c omand_ 1 i re 'S IZE/S) J 
move_bytes(get_ss() , ch_comm 'ADDRESS ,def_seg,def_off, 
data def size) > 



Synchronize process with CCF in order to uass the 
result 

advance(init. ini tial_seg(2) , success ); 

read_evc( init . init ial_seg(0) , evc_ch_val, success }; 

awai t (init . ini tial_seg(0 ) , evc_ch_val+l , success ); 



el se 

end_prog := true; 
end IF; 
end LOOP; 



sU »•< O* »*» 0< O' ' 

— _ y,* 4 



V* »'* »’» O* »'» i 1 * »•« «>< o< o< ,i # .1. 

>,«* *•,«* »,» /,» »,» »|» <’('» *,«» *,w,% /,» /,» 



End of the program and self deletion process 

— detach_devi ce ( STDIO_R, success); 

— detach_device( STDI0_V, success ); 

self_delete( in i t . ini tia l_seg ( 2 ), success ); 
if success /- 0 then 

attach_tew( 10 _ PORT, STDIOJ 1 ); 
put_succ{ SUCCESSOR IS ”, success ,w_class ) ; 
END if; 

END prbdcsJ 



69 



APPENDIX E - COMMON PROCEDURES UTILITY 



This appendix contains the procedures and functions used to 
provide information when the system primitives are used. These were obtained 
from the demonstration program provided by Gemini Computers Inc., and 
modified to reflect a generic use by the application programs developed in this 
research. The programs are "PROCE.LIB" (contains the specifications) and 
"PROCE.PKG" (contains the code developed). 
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WITH agate, agatej, arl, alit, alitj, strlib, util, files; 
PACKAC-F POLY prcce IS 

U3F agate, agatej, arl, alit, alibj, strlit, util, files; 

— Constants for device slots. 

STPIO_V : CONSTANT integer : - l; 

STD IO_R : CONSTANT integer := 0; 

IO_PORT : CONSTANT integer := 0; — port 0 for main 

— Constants for segments. 

SIZE_MENTOE : CONSTANT integer := l; -- size mentor 

-- synchr. segmt 



^ ^ O* J# O# 0#» % l/ 

'i* -v n* -*»* ^ nr -y> nr n H n % n^ *i % n* * 4 «> 



s 1 * %y o* x*# %y o« 

n % n^ n* n % n x n* n % 



— PROCEDURE CR_ SEGMENT 

This procedure completes the parameters needed tv the 
primitive c rea te_ segmen t . The record structure is 
described in the file "agate. lit” provided ty Gemini 
Computers Inc. 

The oarameters received ty this procedure are : 



— 


init 


— > 


initial process definition 


— 


men t or 


— > 


indicates the segment number that 
will be carer.t of this new segment 





ent ryx 


— > 


indicates which entry number of the 
mentor is used to create this segment 


— 


class 


— > 


indicates the security level of the 
segment to be created 


— 


success 


— > 


output variable that indicates the 
result of the operation after call 
the primitive 



This oroceduce is used to create the mentor and 
synchronization segments 



PROCEDURE cr_segment( init : in rl_process_def ; 

mentor : in integer; 
entrx : in integer; 
class : in acoess_clas s ; 
success : cut integer ) IS 



cr_seg_str : create_seg_struct ; 
w_class : access_class ; 

REG IN 
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w_class in it. resources, mi n_ class? 
cr_seg_ s tr . men tor := mentor? 
cr_seg”str . entryx := entrx; 
cr2seg_str . limit := SIZE_MENTOE? 
cr_seg_str . class := class? 

crea te_ segmen t ( cr_seg_str, success )? 
if ( success = 817 ) THIN 

put_ln( STEI0_W, w_class, ”817 means segment already 

exists." ) ; 

ENE if? 

ENE cr_segment? 



*1# %># *1* v># 

^1% /p ^|% ip ^|S /p /p /p /p #p #p ^p #p #p ✓p #p^% *»)* <|% #p ^ <|* #p #p «^p #p /p 






%U %(#> %U 

#p #p ip #p ^p #p /p/p /p /p /p/p zp 



/p ^p 



sU ^'/ \'/ s 1 # 

/p /p /p 



— PROCEDURE ei _ segment 

This procedure completes the parameters reeded by tne 



— 


primi ti ve 


del 


e te_ 


segment. The record structure is 


— 


described 


i n 


the 


file "agate. lib” provided by C-emini 


— 


Compu t ers 


I nc 


• 




— 


The parameters received by this procedure are : 


— 


init 




— > 


initial process definition 


— 


mentor 




— > 


indicates the segment number tnat 
will be parent of this new segment 


:: 


entryx 




— > 


indicates which entry number of the 
mentor is used to create this segment 


— — 


c la ss 




— > 


indicates the security level of the 
s egmen t to be created 


— 


success 




— > 


output variable that indicates the 
result of the operation after call 
the primitive 



PROCEDURE dl_segment ( init : in rl_pr ccess_def ; 

mer.torx : in integer? 
seg_number : in integer? 
success : out integer ) IS 



mentor, entryx : integer? 
w_class : access_class? 

BEGIN 

w_class := ini t . resources .min_class ? 
mentor := mentorx? 
entryx := seg_number? 

del et e_segmert ( mentor, entryx, success )? 
INE dl seg_ t s t ? 
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— PROCEDURE MX SEGMENT 



This procedure corrpletes the parameters needed ty the 
primitive makekn own_se£men t . The.record structure is 
described in the file ’agate. lit" provided ty Gemini 
Computers Inc. 



The parameters received ty this procedure are : 



— 


1 ni t 


— > 


initial process definition 


— 


men t or 


\ 

/ 


indicates the segment number that 
will be parent of this new segment 


— 


ent ryx 


— > 


indicates which entry number of the 
mentor is used to create this segment 


«... 


num ter 


— > 


indicates the number that the segment 
will have in the LDT 


:: 


mode 




indicates the kind of segment that 
will be created (r_w, r_e, etc.) 


— 


success 


\ 

/ 


output variable that indicates the 
result of the operation after call 
the primitive 



This proceduce is used to makekr.own the mentor and 
synchronization segments 



PROCEDURE tk_ segment 



i n i t : in 
mentor : 
entrx : 

number : 
rr. od e : 

success : 



rl_prccess_def; 
in integer; 
in integer; 
in integer; 
in seg_access_type; 
out integer ) IS 



seg_rec : mk_kn_ s t rue t ; 
seg_ret_rec : mk_kn_ re tu rn ; 
w_class : acces s_cl ass ; 



EEGIN 

w_class := i n i t . resources . min _c 1 as s ; 
seg_rec .men tor := mentor; 
seg_rec . en t ryx := entrx; 
seg_ rec . seg_numbe r := number; 
seg_rec . seg_mode := mode; 

seg_rec.prot_level := byte( 1 ); — ring 1 protection 

seg_rec . gat e_numter := NULL_INDEX; — no gate 
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seg_rec . gate_prot := tyte( 2 ) ? 

makekncwn_segment ( seg_rec, seg_ret_rec, success )? 
END mk_segment? 



«<« »l» »•/ *V* O# »v »*• »•* «>« »<« «<« <A< J# *l» »'# ^ 0< Of <(« 

V ^|> »)' »p »i» »y 'f« *(* v *j» v <r* *v *r* ^ #|* <|» #(* «f* ^ »p 



- 1 , o< y • %■< y* y# >*• v* y* y<* y# y» V* y «» y # «)« y* k'o j» y* y* v* y* y* »'* *'o y* y* y- y* *'/ y* y* y* *v %*g y » y* »'« y* *'o y« %»« y« y* *>o »>o y* 

^ ^ , 5 |% #|* »,* 5 |> }|« #|% 0 |\ J ( « 0 | * 0 |« J|» O t « J|^ op Op op Jp Op V op Op Op op op op Op op Op Op op # 1 % op 0 |< O | » op op op Op op Op Op op Op op Op 



— PROCEDURE MAKE_KNOVfN_S'!NC 

This procedure effects several actions related to the 
creation of special segments to synchronize the main 
application program with the active user. Since the 
segments were created hy the active user this procedure 
will only makeknown those in its own LET tatle, and 
swapin these in memory 



— The parameters received ty this- procedure are : 



— 


init 


— > 


initial process definition 


— — 


ch_uara 


— > 


indicates the parameters used to 
create the user handler process 


— — 


ch_ class 


— > 


indicates the access_class of the 
segment to he created 




ch _ac t i ve 


— > 


indicates which active user is 
trying to communicate with 


— 


ch_user_sync 


— > 


is an output record that contains 
the segment numbers assigned to the 
synchronization segments 


— 


success 


— > 


output variable that indicates the 



result of the operation after call 
the primitive 



This procedure is used to makeknown the synchronization 
segments (main application - active user) 



FRCCEDURE make_kn cw_ sync ( init : in rl_process_def ? 

ch_para : in rl_pararreter s ? 
ch_class : in access_class» 
ch_active : in integer? 
ch_user_sync : out users_act ive? 
success : cut integer ) IS 

mentor : integer? 
entr.yx ; integer? 
seg_mode : seg_access_ty pe ? 
seg_number : integer? 

class : access class ? 
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BEGIN 



make known root segment (code segment of each child) 

mentor := ch_para . seg_number_ccde; 
entryx := 35 

seg_number := ch_para . syr_chr_chld_men tor? 
seg_mcde := r_w; 

class := ini t .resources .min_class5 
mk_segment ( ini t .rnent or , entry x , seg_ number , 

seg_mode , sucres s ) 5 

if success / = 3 then 

put _succ ( " success value 336 is ” f success ,ch_class ) ? 
put_ln(ST2IC_W f ch_class,”)5 
end if! 

make known stack segment 

mentor := ch_pa ra . sy nc b r_chld_ment or 5 
entryx := 15 

seg_number := ch_para . synchr_chld_st ack 5 
seg_mode := r_w5 

mk_ segment i in it, men tor , entryx , seg_ number, 

seg_mcde .success } 5 

if success /- 0 then 

put_succ( "success value 0S7 is ” , succes s , ch_c la ss ) 5 
put _ln ( STDI0_W , ch_cl ass , ” " ) 5 
end if; 

make known data segment 

mentor := ch_para . sy nchr_chld _ment or 5 
entryx := 25 

seg_number ch_para . synchr_chld_data ; 
seg_mode := r_w? 

mk_segmen t ( i ni t , men t or , entryx , seg_ number , 

seg_mode, success) ; 

if success /-- 0 then 

put_succ ( "success value 009 is ", success ,ch_rla<;s ) » 
put_ln(STDI 0_W ,cb_class , "" ) ; 
end if; 

ch_user_sync(ch_active) .seg_data : = 

ch_para . syn cnr _ chi d_ da ta ; 
cfc_user_sync ( ch_ac ti ve ) .seg_stack : = 

ch_para . synchr_chld_ stack; 

swapi r._ segment ( ch_user_syrc ( ch_act ive) . seg_data , 

success ) 5 

read event counts of each segment 

read_evc ( ch_user_sync ( ch_ac t. i ve ) . s eg_da ta , 

ch _user_sync ( ch_ac ti ve } .evc_data, success) 5 
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te rmi na te _ segmen t ( 44, success) i 
if success /= <? then 

put_succ( ” success value is " , succes s ,ch_c la ss ) * 
put_ln (S TCI G_W,ch_c lass, "”) » 
end if; 

END make ’Know sync; 



O# %*# O# %*# W 1 # %*# %*# %(# X i/ x*^ %U x^# X^ %l# x«> 

^1' n' -r* r i % ^p ^p ^p ^p ^p ^p «p #p rp #p #p #p #p #p ^ /,% # ( % 



M 5|C #|% i|C 3|X 2p Ip 3|C Ip 



j 1 # 






%*<• %V %*/ %V %V k 4 # % ( # %*# X*/ %*# %** « ' # %•# %(# %L «,!# X *« % ( # X I ^ X *V 

*1^ *1^ ^p *1^ # p •’p ^p ^p «p #p *p #p #p /p «p /p tf p #p «p ^p #p / p 



— PROCEDURE TERM INATE_ST NCHR_SEG 

This procedure terminates the segments makeknovn 
previously with the object to synchronize the communica- 
tion between an active user and the rain appl . program 

— The parameters received by this procedure are : 



— 


in i t 


— > 


initial process definition 


— 


ch_para 


— > 


indicates the parameters used to 


_ _ 


ch_class 


--> 


create the user handler process 
indicates the access_class of the 




success 


— > 


segment to be created 

output variable that indicates the 



result of the operation after call 
the primitive 



This proceduce is used to delete the synchronization 
segments created before (main - active user; 

FRCCEEURE terminate_s,ynchr_seg( in it : in rl_process_def; 

ch_para : in rl_pararet ers ; 
ch_class : in access_cla ss * 
success : out integer ; IS 



terminates the segments created to synchronize main 
application program with the process created by the 
child process leaving available the segment numbers in 
— the IDT 



EEG I N 

t er m in at e_s egrrent ( ch_para . syr.chr_chld _da ta , success )J 
t ermine te_ segnen t ( ch_pa ra . synchr_chld_s tack , success ); 
END termir.ate_synchr_seg ; 
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— PROCEDURE ? ILL_ I N I T 

This procedure fills the process definition record with 
the data provided in the initial process definition plus 
the resorces that the parent will pass to his child and 

— the access class of this specefic process 



The parameters received 'ey this procedure are : 



— 


init 


— > 


initial process definition 


— 


ch_ini t 


— > 


output process definition 


— 


ck_res curce 


X 

/ 


indicates the resources passed ty its 


— 






paren t 


— 


success 


— > 


output variable that indicates the 


— 






result of the operation after call 


— 






the primitive 



PROCEDURE fill_init( init : in rl_process_def ; 

ch_init : out rl_process_def ; 
ch_resource : in child_resource ; 
ch_access : level_record ) IS 

fill in the initial process record of a child 
process called Try crt_proc_tst . 



ch_init.cpu := init.cpu; 

ch_in i t . num_ epu := ini t ,nurr_cpu j 

ch_init .num_kst := init .num_kst ; 

ch_init.rcct_access := init.rcot_access; 

ch_in it . s_seg := 35 

ch_i nit. resources. priority : = 

ini t . resources .pri ori ty ; — same as parent. 
t24_f rm_in t eger ( ch_ re source .memory t 

ch_ini t . resources .memory )j 
ch_ in i t . res curce s . pr cce sse s t- ch_resource .processes » 
ch_init . resources .segmnts := ch_resource .segments* 



this will he modified with the specific access class 
of each process 



ch_in i t . res ources .mi n_cla ss := 
ch_init . resources .max_class := 
ch_init.ring_r.um : = ty t e ( 1 ) ; 



ch_ access. min » 
ch access.max; 
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I 



i 



ch ini t . sp2 := 0 ; 
END fill init; 



-r* * 












* 



*•# »•» %•# »•< »'# %•» »•» *•» *•* «.'< »•< »•< »•< *'» o# *•< 

w y # ( » «|« »j\ »,» /|« » ( > y,<» y,^ /)« *|» /(» #|« 



»'< »'< »•# %•< »’» V' V' »•* *'» %'y %'y *'« »•# »'» »*< *'* *'/ »•» »'< »'y %'y >'< %ly %*y 

<i» y,* y ( ' y,^ '(* /|> y,* / ( « y,* y ( » y,* y,» y,» y,* y,’ y,% y,» y,* y,» <,» / ( « y,» y,% y,* y,«» y,% 



— PROCEDURE CR_FROCSSS 

This procedure performs all the operations necessary to 
create a child process, this operations include 
makekncwn the code segment of the child, creation of 
stack and data segments, fill the addess space 
specification and process creation 

The parameters received ty this procedure are : 



— 


init 

ch_uar 


1 1 
1 1 

\/ \/ 


initial process definition 
parameters to create a child 
(segment nurters , entry numbers, 


-to) 


““ ““ 


process 


— > 


indicates the process numter to 
created (example active user 1 


1 e 

/ 




ch_res ource 


— > 


indicates the resources that th 
child will have 




— 


synchr_seg 


— > 


indicates the segment that is u 
to synchronize this new process 
its parent 


sed . 
wit h 


— 


success 


— > 


output variable that indicates 
result of the operation after c 
the primitive 


the 

all 



PROCEDURE cr_prccess( init : in rl_process_def; 

ch_par : in rl_paramet ers » 
ch_access : in level_record \ 
proces : in integer* 
ch_resource : in child_res ource ; 
synchr_seg : in integer; 
success : cut integer ) IS 



chld_seg : rl_seg_s truct ; — rl_addr_array for child • segment 
ch_init : rl _pr cce s s_def *» — rl_process_def for child 

seg_rec : create_seg_struct; — used to create stack segment 
segl_mkn : mk_kn_ struct; -- used to make known stack segment 
segl_ret : mk_kn_return ; 

crt_rec : rl_cp_struct; — create process structure 

ch_ieg_list : seg_array» 
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ch_inpt_mess : input _mes sage 5 
data_aef_size : integer; 
end_chld t boolean; 

w_class : aecess_class ; 
evc_value : integer! 
stack_size : integer! 
seg_mgr_by te s : in t ege r ! 
de?_off : integer! 
def_seg : integer! 
rl_def_size : integer! 
dummy : integer! 

— constants for determining stack size 

rl_stack_size : CONSTANT integer := ie#AFF#! 
vect_size : CONSTANT integer := 4! 

BEGIN 

w_class := ch_access .min ! 

segl_mkr .men t or := ch_uar .rent or_c ode ! -- appl. root 
segl_mkn.entr.yx := ch_par . en t ry_ code ! 
segl_mkn . seg_number := ch_par . seg_number_c ode ! 
segl_mkn . seg_mode := r_e! 
segl_mkr. .pro t_ level := byte ( 1 )! 

segl_mkn . ga te_number := NULL_ INDEX! — no gate 

makeknown_segment ( segl_mKn, segl_ret, success )! 
if success /= 0 then 

put succ ( "success value is " f success ,w_class ) ! 
put_ln(5TDI0_W ,w_class , ” " } ! 

ENE IF! 



address spec for child's stack 

chld_seg.seg_n umber := ch_pe r . seg_numbe r_s tack ! 

chld_seg . seg_mode := r_w! 

chld_seg . swapi n := TRUE! 

chi d_seg .protect := tyte( 1 }; 

cr t_rec . rl_addr_array ( 0 ) := chld_seg! 

address spec for child's code 

chld_seg . seg_number := ch_pa r . seg_number_c ode ! 

chld_seg . seg_mode := r_e! 

chld_seg . swapi n := TRUF! 

chld_seg. protect := tyte( 1 }! 

crt_rec . r l_addr_array ( 1 ) := chld_seg! 

address spec for child's mentor 



SS 



chld_seg . seg_numter := synchr_seg? 

chld_seg . seg_mcde := n_a? 

chld_seg . swap in := TRUE? 

ch Id _ seg . pr c tec t := tyte( 1 )? 

cr t _rec . rl _add r_array ( 2 ) := chld_seg? 

address spec fcr trap handler segment 

chld_seg . seg_numte r := i r.i t . in i t ia 1_ seg ( 4 ) ? 

chld_seg . seg_mode := r_e? 

chld_seg.sv/apin := TRUE ? 

chld_seg .pr ctec t := byte( 1 ); 

crt_rec . rl_addr_array( 4 ) := chld_seg? 

address spec fcr child's data 



chld_seg . seg_rumber := ch_par . seg_number_d ata ? 

chld_seg. ses_mode := r_w? 

chld_seg . svapin := TRUE? 

chld_seg. protect := tyte( 1 )? 

cr t _re c . r l_add r_a rra y ( 3 ) := chld_seg? 



fill the order in which the segments will he passed 



ch_seg_list(0) 
ch_ seg_ 1 i st ( 1 ) 
ch_seg_l i s t ( 2) 
ch_seg_l ist (3 ) 
ch_seg_ list ( 4 ) 



ch_par . seg_ number _sta ck? 
ch_par . seg_num ber_o ode ? 
synchr_seg? 

ch_par.seg_number_data? 
init .initial_seg(4) ? 



calculate required stack size. 

(in the future will calculate based on data in "CMU" 
file header but now just use constant.) 

seg_rrgr_by tes := ( s tackheader 'SI ZE/S ) + 

( i n i t . n um _ k s t * ( kst_entry'SIZF/S )) + 

( kst_header 'SIZF/S )? 

stack_size := rl_stack_size+vect_size+seg_mgr_by tes 

( rl _pr ocess _d ef ' S I ZE/8 )? 

create and make known child's stack segment 

seg_rec. mentor := ch_par.mentor_stack? 

seg_rec . entryx := ch_par .entry_stack? 

seg_rec . 1 imi t := stack_size - 1? 

seg_rec . class := ch_ac cess, max? -- sis*#*#**??* 

create_ segment ( seg_rec, success )? 

if success /= 0 then 

put _ succ (” success value aa is ", success ,w_class } » 
pu t _ 1 n ( S T E 1 0 _ W , w_ c 1 a s s , ” " ) ? 
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IND if; 

segl_mkn . men tor := ch_pa r . men t or_ s tack ; 
segl”mkn . entry* := ch_ - car.entry_stack; 
segl_mkn . seg_number := ch_par . seg_nunter_s tack; 
segl_mkn . seg_mode := r_v; 
segl_mkn . pr ot_level := byte( 1 ); 
segl_mkn .ga te_number := Nl T LL_INDIX; 
segl_mkn . gat e_pro t := byte' 0 ); 
makekncwn_segment ( segl_mkn, segl_ret, success ); 
if success / = 0 then 

put_ succ ( "success value j is ", success , w_cla ss ) » 
put In (STDIO V ,w_class , ; 

IND IF? 

swapir._ segment- ( ch_par . seg_numter_ stack , success ); 
if success /= 0 then 

put_succ( "success value.! is ", success , w_cla ss ) ! 
nut In ( STDI0_W , v_class , " " } ; 

IND IFT 



create and make known child's data segment 



seg_rec .mentor := ch_par .rcent or_da ta ; 
seg_ rec . en t ryT : = ch_par . en try _ data ; 
seg_rec . 1 im it := input _message 'SIZI/8* 
seg_rec . cla ss := ch_access .max ; — 

create_ segment ( seg_rec , success ); 
if success /= 0 then 
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put_succ ( "success value.cc is ", success , w_c la ss 
put ”ln ( STDIO _W ,w_cl ass ,"") » 



IND if; 



\ . 

/’ « 



segl_mkn . men t or := ch_par .mentcr_data; 

segl_mkn . entryx := ch_par. entry_da ta ; 

segl_mkn . seg_rumter := ch_par . seg_number_dat a ; 

segl_mkn . seg_mode := r_w; 

segl_mkn . pro t_ level := byte( 1 ); 

segl_mkn . ga te_r.umber := NULL INDIX; 

segl_mkn . ga te_pro t := byte! 0 ); 

makekn cwn_segment ( segl_mkn, segl_ret, success ); 

if success /= 0 then 

put_succ( "success value.c is ", success ,w_cla ss ^ » 
put n ( STDIO_ V ,w_cl a ss , " " ) * 

IND if; 

swapin_ segment ( ch_par . seg_rumber_da ta , success )» 
if success /= 0 then 

put_succ( "success value A is ", success ,w_class ) J 
pu t In ( STD I 0_ V , w_cl ass , ” " ) ; 

IND IF? 



fill in childs rl_pr oce s s_def 

fill_init( init, ch_ir.it, ch_resource, ch_access ); 
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determine segment 5. offset of rl _prcce s s_def initial 
record 

def_seg := lib_mk_sel( ldt_table, 

ch_pa r . seg_number _ s tack }; 
def_off := stack_size - ( vect_size + seg_mgr_ bytes 
rl_proces s_def 'SIZE/8 )» 

move ch_init into proper place in child's stack segment 

rl_def_size := ( rl_pr ocessdef ' 51 ZF: )/8j 

move_bytes( get_ss(), ch_ini t 'address , def_seg, def_cff, 

rl def size ) ; 



fill in remainder of create_process_structure 

crt_rec.ip := 128; — skip command file header (8? hex ^ 

crt_rec.spx := def_cff; -- set childs stack pointer 

crt_rec.spl := stack_size - (vect_size + seg_mgr_by te s ) ; 

crt_rec.sp2 := 0; — no ring 2 stack 

crt_rec . vec_ seg := 8; -- rl address array element 8 

cr t _rec . vec _ of f := steck_size - vect_size» 

cr t _rec . chi ld_num := proces-i; 

crt^rec . pri ori ty := ch_ini t .resources .pri ori ty I 
cr t_ rec .mem ory := ch_ in i t . res our ces . memory »* 
cr t_rec . processes := ch_ini t . res ources . processes ; 
cr t_rec . segmnts := ch_init .resources. segmnts? 
crt_rec .min_class := ch_init .resources .min_class ; 
crt rec. max class ch ini t . resources .max class? 



— read event count so ve know when child has self_deleted 

read_evc( syr.chr_seg, evc_value , success ); 

create the process 

cr e at e_pr oc es s ( crt_rec, success ); 
if success /= 0 THEN 

put_succ( " create process success = ", 

success , w_clas s } ; 



END if; 



END cr_process; 
END proce; 



102 



WITH' agate , agatej, arl, alifc, alitj, strlit, util, files? 
PACKAGE proce IS 

US i agate, agatei, arl, al it , alitj, strlit, util, files; 



"i' V *v 



V* '»* 'i' 



5 l » ^ »•* »'» »•» >A» »•/ »■# • *’» 

»)» ^|V < ( » /|> */% ^1' <|» 
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— THIS PROGRAM IS PROCE. LIB 

Contains the specifications needed ty PROCE.PKG prcgrarr 



PROCEDURE cr_segment( init : in rl_process_def ; 

mentor : in integer; 
entrx : in integer; 
class : in access_cl ass; 
success : cut integer ) ; 



PROCEDURE dl segment 



init : in rl_prccess_aef ; success : 
out ir.t eger ) ; 



PROCEDURE mk_ segment ( init : in rl_prccess_ief; 

mentor : in integer; 

entrx : in integer; 

number : in integer; 

mode : in seg_access_type ; 

success : out integer ); 

PROCEDURE rrake_know_Sync ( init : in rl_process_def ; 

ch_para : in rl_parameters ; 
ch_class : in access_class; 
ch_active : in integer; 
ch_user_sync : cut users_act i ve ; 
success : out integer); 

PROCEDURE terminate_synchr_seg(init : in rl_process_def; 

ch_para : in rl_parameter s ; 
ch_class : in access_class; 
success : out integer 1 ); 

PROCEDURE fill_init( init : in rl_process_def ; 

ch_in.it : out rl_process_def ; 
ch_resource : in child_rescurce ; 
ch_access : in level_rec ord ) ; 

PROCEDURE cr_prccess( init : in r l_process_def ; 

ch_para : in rl_parameters ; 
ch access : in level record; 



ies 



prcces : ir. integer! 
ch_resource : in chi ld_re s ou rce ; 
synchr_seg : in integer? 
success : cut integer); 



EMC pr cce ; 



104 






APPENDIX F - SERVICE ROUTINES AND ADDITIONAL DATA STRUCTURE 



This appendix contains the procedures and functions used by 
the application programs related to execution of I/O operations. It also contains 
additional data structures necessary to run specific application programs 
(parameters, record’s description, constants, etc.). The program is "Files" and is 
composed of two modules. "FILES. LIB" (contains the specifications of records, 
functions and procedures used) and "FILES. PKG" (contains the code developed 
for each procedure or function). 
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WITH agate, agatej, arl , alit, alitj, strlit, util; 
PACKAGE B C E.’Y files IS 

USE agate, agatej, arl, alit, alitj, strlit, util; 

STDIO_W : CONSTANT integer := i; 

STD I C_R : CONSTANT integer := 0; 



PROCEDURE t24_f rn_integer( in_val : in integer; 

t24_val : out t24_tvoe ) 1 5 

Routine to convert an integer into a 
B24_type variable ( 3 -bytes ) 

BEGIN 

b24_val . by fe2 := tyte( 0 ); 
b24_ va 1 . by tel := hi( in_val ); 
t24_val . by te0 := 1 o ( in_val ); 

END b24_f rr_i n t eger ; 



PRCCEDURF put_ln ( ldev : in integer; 

w_class : in access_class; 
str : in string ) IS 

put a string on device ldev with cr and If 

out_tuf : strir.gf 82 }; 
success : integer; 
wt_sio : wt_seq _struct; 
size_str : integer; 

CR : CONSTANT integer := 13; 

LE : CONSTANT integer := 10; 



BEGIN 

out_tuf := str; 

size_str := length( str ); 

cut_tuf := cut_buf & char_to_str( character 'val ( CR )); 
out_tuf := out_buf 6. char_tc_str( chara c te r ' va 1 ( LE )); 
vt_si o .devi ce := ldev; 

wt _s i o . d ata_ of f := out _buf 'ADDRESS + l; 

wt_si o .da ta_ seg := get_ss(); 

wt_sio. count := size_str + 2; 

wt_sio. class := w_class; 

wr i te _ sequen ti a 1 ( wt_sic, success ); 

END put_ln; 



PROCEDURE tlk_scr ( ldev : in integer; 

w_class : in access_class; 
str : in string ) IS 
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Blank the screen and put the cursor in the 
first position 

out_tuf : string 82 ); 
success : integer? 
wt_sio : wt _seo _ st rue t ; 
size_str : integer; 

ESC : CONSTANT integer := 27; 

E : CONSTANT integer := 45; 

BEGIN 

cut_tuf := str; 

size_str := length ( str ); 

out_tuf := out_huf 6, char_tc_str{ charac ter ' val ( 
o u t _ h u f := cut_tuf 5, char_to_str( character 'val ( 
w t _ i i o . device := ldev; 

wt _si o .data_ cf f := cut _tuf 'ADDRESS + l; 

wt_sio.data_seg := get_ss(); 

wt_sio. count := size_str + 2; 

wt_sio. class := w_class; 

wri te_seouential ( wt_sio, success ); 

END tlk scr5 



PROCEDURE get_str ( ldev : in integer; 

r_class : out access_class ; 
str : out string ) IS 

get a string frorr device ldev. 
in_tuf : string' 62 ); 
success : integer; 
rd_sio : rd_seq _struct; 
rd_ret : rd_seq _ return ; 
size_str : integer; 

BEGIN 

rd_sio.data_off := in_tu f 'ADDRESS + 1 ; 

rd_s i o .devi ce := ldev; 

rd_si o. data_ seg := get_ss(); 

read_sequen t ial ( rd_sio, rd_ret, success ); 

in_huf( O ) := character 'val ( rd_re t . c our.t ); 

str := in_huf; 

r_class := rd_ret .cl ass ; 

FND get str; 



PROCEDURE put_str ( ldev : in integer; 

w_class : in acces s_cl ass ; 
str : in string ) IS 
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put a string on device ldev. 

out_tuf : string’* 
success : integer* 
vt_sic : wt_seq_struct; 
size_str : integer; 

BEGIN 

out_tuf := str; 

size_str := length( str ); 

wt_sio.device := ldev*, 

wt_si o.data_cf f := out _ tuf ' ADDRESS + l; 

wt_sio .data_seg := get_ss(;i 

wt_sio. count := size_str; 

wt_sio. class := w_class; 

wri te_sequential ( wt_sio, success ); 

END put_str? 



PROCEDURE. put_dec( ldev : in integer; 

w _ c 1 a s s : in access_class; 
dval : i r. integer ) IS 

put the string equivalent of a integer on the terminal 
— screen. 

out_tuf : string( 1C ) » 

BEGIN 

ou t _ tuf := Int_to_str( dval ); 
put_str( ldev, w_class, cut_huf ); 

END put_dec; 



PROCEDURE put_succ( ir._str : ir. string* 

dec_val : in integer; 
w_class : ir. access_class ) IS 

print a string ar.d an i r.t eger on device attached in 
slot STDIO V (should te a serial terminal). 



BEGIN 

put_str( STD I0_'* i , w_class, in_str ); 
put_dec( STEIO_W, w_class , M dec_val )’> 
put_ln( STDI0_V, w_class, ’’ ); 

END put_succ; 
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FUNCTION get_input( eco : in boolean? 

rd_class : in access_class ) RETURN string IS 

Gets an input string from the terminal and echoes the 
input if the echo option is on. It also converts all the 
input tc lower case 



constants 

STEIO_R : CONSTANT integer := 0? 

STDIO_W : CONSTANT integer := 1J 

rd_str : string? 
ind : integer? 
values : integer? 
inp_ch : string ( 1) ? 

w_class : access _cl as s ? end _i nput : boolean? 

BEGIN 

w_ class : = rd_class? 

end_input := false? 

ind : = 1 ? 

rd_str := ”"? 

while not end_input LOO? 

get_str ( STDIO_R , w class, inp_ch)? 
if inp_ch(l) in 'A^..'Z' then 
inp_ch(l) := 

character' val(character , pos(inp_c.h(l)) +32;? 

end if ? 

if ( character 'pos ( i np_ch ( 1 ) ) = 13 ) then 
end_input := true? 

else 

if eco then 

put str( S T D 1 0_ Vj , rd_cless, inp_ch )? 

ENE IF? 

rd_str := insert( inp_ch, rd_str, ind )? 
ind := ind + 1? 
end if? 
end LOOP? 

RETURN rd_s tr? 

ENE get_ input? 

PROCEDURE attarh_tew( IO_PORT : in integer? 

LEEV : in integer) IS 

attach serial port for writing. 
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rode 

w_class 

success 

BEGIN 



attach _struct: 
access_class; 
i n teger : 



rrode . dev _ parr e := siow? 

mode . si ow_rec .dev_nurr := io_port; 

mode . siow_rec .dev_type := i c ; 

mode . sicw_rec .dev_id := LDEV : 

mode . si ov_rec . mrl := byte( 16#04D# ): 

mode . si ow_rec . mr2 := byte( 16£03E# ); 

mode. sicw_rec . io_mode := asrt_rts; 

at tach_device( mode, success ): 

END attach_tew5 

PROCEDURE attach _ter( IO_PORT : in integer; 

LDEV : in integer) IS 

attach serial port for reading. 

mode_r : at tacfc_struct ; 

w_class : acces5_class; 

success : integer: 

BEGIN 

mode_r .dev_name := siorJ 
mcde_r .sior_rec .dev_num := io_port; 
mode_r . s i or_ rec . dev_ ty pe := io*» 
mode_r . si cr_rec .dev_id := LDEV ; 
mode_ r . si or_ rec .mrl := hyte( 16#24D# )» 
mode_r . si or'rec . mr2 := bytev 16£03E6 ); 
mode_r . si or_rec . io_m.ode := asrt_dtr; 
mode_r . si cr_rec .delim_acti ve := FA.LSE5 
rode_ r . s i or_ rec . del imi t er := byte( 13 ): 
mode_r . s i or_rec .maximum := 1J 

— only reads one character at a time, 
at t achd evi ce ( mode_r, success )? 

END attach ter: 



PROCEDURE load_param (ini t : in rl_process_def : 

ch_para : out rl_param) IS 



— Produces a table of parameters with information needed 
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ty the main application pregram (segment number, entry, 
mentor). 

INITIAL : CONSTANT integer := 31* 

NEXT _ NUMB IR_FRE I : CONSTANT integer := 40; 

CH_SYNCHR_NENTC’R : CONSTANT integer := 44; 

index : integer; 
nex t _s egment : integer; 
data _n umber : integer; 
ch_naram : rl_parameters; 
usr_level : level_record ; 
synchr_chld : integer; 



BEGIN 

nex t_segrren t := INITIAL; 

da ta _number := N El 'T _ NU MB ER _ FREE ; 

synchr_chld := C H _ S YNC HR _ NT N T OR + l; 

— next segment available 

index := i; 

while index < 5 LOOP 

ch_pa ram . en t ry_ s tack := index; 

ch_param.mentor_stack := INITIAL; 

next_segment : =~next_segrrent x l; 

ch_pa ram . seg_number_stack := nex t_segment ; 

next_segment := nex t_segmer. t + i; 

ch_pa ram . seg_number_code := nex t_segmen t ; 

ch_pa ram . en try_c ode := index + 6; 

ch_param.mentor_code := init.initial_seg(2); 

ch_pa ram . en try_da ta := index + 4; 

ch_pa ram . ment or_data := INITIAL; 

ch_parar . seg_number_da ta := data_number ; 

data_number := data_number + i; 

if index < 4 then 

ch_param . synchr_chld_mentor := CH_SYNCER_MENT0R ; 
ch_param . synchr_chld_s tack := synchr_chld; 
syn chr_ chid := synchr_chld 1 ; 
ch_param . synchr_chld _data := synchr_chld; 
synchr_chld := synchr_chld + l; 
else 

ch_oaram . synchr_chld_me nt or := 3; 
ch_pa ram . synchr_chld_st ack := 3,* 

ch_param . syn chr_chld_da ta := 0 ; 

END ie; 

ch_para ( i nd ex ) := ch_param; 
index := index + i; 

END loop; 

END load_param; 
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PROCEDURE load_access_class ( init : in rl_proce ss_de f ; 

usr^access : ~ out user_level ) IS 

Produces a ta fc le with the security access level depen- 
ding on the user level 



usr level : level record; 



BEGIN 

usr_level .min . compromi se .into := 0j 
us r_l evel .m ir. . comprcrri se . inti := 0 ; 
usr_ level .min . integrity .into := 0 ; 
usr_l evel .m in . integrity . inti := 21504; 
usr_level .max .compromise .into := 6; 
usr_level .max . compromi se . inti := 0; 
usr_level .max. integrity. into := 0 ; 
us r_l evel . max . i n tegr i ty . i at 1 := 21 504; 



usr access-TOP SECRET) := usr level; 



usr_l evel. min. compromise. into 
usr_level .min. com promise. inti 
usr_level .min .integrity .into 
usr_level .min. integrity. inti 
us r_l evel. max .compromi se .into 
usr_level .max. com premise. inti 
usr_l evel. max. integrity. into 
usr_level. max. integrity. inti 
usr acces s { SECRET ) := usr level; 



rt 

Yj 



J 



o; 

0 ; 



21 504 ; 

4; 



n • 

iJ 1 



•?; 

21504J 



usr_level. min. com promise. into 



rt • 

c 1 



usr_level .min. compromi se . inti : 
usr_level.mir. integrity .into : 
us r_l evel .mi n . i n tegr i ty . i n t 1 : 
usr_level. max. compromise. into : 
usr_level .max. com promise. inti : 
usr_level .max . integrity . into : 
usr_level .max .integrity .inti : 
usr acces s ( CONE IDENT IAL ) := usr 



= 0; 

= O; 

= 21504 

_ ^ • 

— C j 

rx • 

~ YJ J 

= 0; 

= 21504 
level ; 



J 



usr_level .min .compromise .into 
usr_level .min. com promise. inti 
usr_level .min .int egr i ty .into 
usr_level.min .integrity. inti 
usr_level .max .compromise .into 
usr_level. max. compromise. inti 
usr_level .max .integrity .into 
usr_level .max .integrity .inti 
usr access (UNCLASSIFIED ) := u 



:= O; 

:= 0 ; 

• o • 

• - t) 1 

:= 21504; 

: - yj j 
:= 0 ; 

:= O; 

:= 21504; 
sr level? 
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END load access class* 



PROCEDURE 1 cad_ paraml ( in it : in rl_prccess_def ; 

ch_param : out rl_pa rarre ters ) IS 

Produces a tatle of parameters with information needed 
hy the User Handler 



MENTOR : CONSTANT integer := 315 

BEGIN 

ch _ pa ram . en try _ stack := l; — always 1 

ch_pa rarr . men tor_ s tack := MENTOR? 

ch_param . seg_numher_stack := 32? — ” -32 

ch_pa ram . seg_numter_code := 33’ 
ch_param . er.try_ccde := 4? 

ch_pa rarr . men tcr_code := in i t . i ni tial _seg( 1 ) ? 
ch_pa ran . en try _da ta := 2? 
ch_param .rrentcr_data := MENTOR? 
ch_param . seg_nurber_aa ta := 34? 

END 1 oad_paraml ? 

PROCEDURE load_child_act ive 

(usr_active : out use r s_ac t i ve ) IS 

Initializes the Active User record to FALSE. It lets 
CC? load the Active User segments each time a false 
record is found 



index : integer? 

BEGIN 

index := 1? 

while index < 3 LOOP 

usr_active( index ) .active := FALSI? 
usr_act ive ( index ). seg_data := 0? 
usr_act i ve ( index ). seg_s tack *.= 0? 
usr_act ive ( index ) .evc_data := 2? 
usr_active( index ) .evc_stack := O? 
index := index + 1? 
end LOOP? 

END 1 oad_child_active? 

PROCEDURE look_for_level (username : in string? 

password : in string? 
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ch_access • in user_levei; 
ch_class : out acces s_cle ss ) IS 

Simulates the Logon process, loading the access class cf 
the user depending on the Username and Pasword 



BEGIN 

if password = 
ch_class : = 
elsif password 
ch_class := 
ELSIE password 
ch class : = 



falconl” then, 
ch a cces s ( 1 ) .max ; 
= "falcon" then 
ch access (2). max; 
= "secret" then 
ch access (3 ). max i 



ELSE 

ch_class : = ch_a cces s ( 4 ) .max ; 
END ie; 



END lock for level; 



FRCCEDURE in i t i a 1 i z e_ t a t le s ( seg_ t a hi e : out files_data; 

seg_head : out segment _header ) IS 

Initializes the internal tables that will simulate the 
automatic creation of segments numbers using the LET 
table 



index : integer; 

w class ; access class; 



BEGIN 

w_class.integrity.int0 := 0 ; 
w_c lass. integrity. inti := 0 ; 
w_c lass .compromise .inti := 0 
w_c lass .c ornpr omise . in t0 := 0 
seg_head.max_files_stored 
seg_heaa . rex t_avail_s eg 
seg_head . nex t_avai l_ent 
seg_head .nex t_avai l_men 
seg_head .max_ open _s eg 
se g_ head .max _ open _ent 
seg_head .max_ open men 



VJ 1 

IN ITI AL_ERES_SEGMSNT ; 
INITIAL_FREE ENTRY; 
INITIAL FRSE_MEN‘ToR; 

initial~free_segkent ; 

INITIAL FREE ENTRY; 

I N IT I al'free mentor; 



initialization of array that holds files information 



index := 0; 

while index < MAX _NUMBER_OF_ FILES + 1 LOOF 

seg_tatle ( index ) .number := 0; 

s eg_t abl e f index ). en try s := 0; 
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seg_tatle( index) .mentor := 0; 

seg_ tat le ( index ). f i le_name := * 

seg_table{ir.dex ) .access_cla := w_class; 

seg_table{ index ) .next_avail_seg := INITIAL_FREE_SIGMENT 

seg_table ( ind ex ) . next _a va i l_en t := IN' IT IAL_FRFF~E NTRY ; 

seg_tatle( index ). next _avai l_men := I NI TI AL_FREE_MENT0R 5 

index := index + i; 

end L00F5 

IND initialize_tables ; 

FUNCTION check_if_exists_file_name 

(seg_table : in files data; 

file_name : in string! R FT URN boolean IS 

— check if file name declared in input command exists or 
does net 

index : integer; 

answer : boolean; 

BIGIN 

index := 0; 
answer := FALSI; 

while index < N:AX_NU^BER_OF_FI LES + 1 LOOP 

if seg_ table ( index ). f ile_name = file_name then 
answer := TRUE; 

RETURN answer; 
else 

index := index + i; 
end IF; 

end loop; 

RETURN answer; 

FND check_if_exists_f ile_name ; 

PROCEDURE con vert ( ch_in : in inpu t_mes sage; 

w_class : in access_class; 
ch_out : out corrand-_line ) IS 

this procedure assembles the commad line using the input 
message typed by the user 



index : integer; 

index 1 : integer; 

temp : string; 

inp_ch : string(l); 
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BIGIN 



1 



temp := 

index := 1» 

indexl := i; 

while (( index <= 40 ) 

and (index <= leng th ( ch_i n . i npu t_ one ) ) ) LOOF 

if ( ( ch_in . input_cne ( i ndex ) in ) or 

( ch_i n . inpu t _ one ( i ndex ) in ' 0 '..' 9 ' )) then 
temp (indexl) := ch_in . input _ one ( index ) ; 
indexl : = indexl + 1 : 

else 

if (( character 'p o s ( ch_ in . inpu t_ one ( index ) ) = 32) 

and 

( index /= 1 ) and 

( character 'pos ( ch_in . input _ one ( index-1 ) ) /= 32)) 

then 

terrp( indexl ) := ch_in . inpu t_ one( i ndex } ; 

indexl := indexl l; 

else 

i f 

(( character 'pos ( ch_ i n . i nput_ one ( i nd ex ) ) - 94) 

or 

(character'pcs(ch_in.input_one(index)) = 125;) 
indexl := ir.dexl - l; 
t emp ( i ndex 1 ) := ' '; 
end if; 
end if; 
end if; 

index := index + l; 
end LCCP; 

load command line 

ch_out . command := _ "; 

ch_out . f il e_namel := " ; 

ch_cut . f il e_name2 := ’’ "; 

ch_out. comma r.d_class : = ch_in.input_class; 

index : = 1 ; 

indexl := l; 

loop to fill command 

while (( cha ran te r 'po s( temp ( index ) ) /= 32) and 
(indexl < 9 )) LOOF 

ch_ out . c ommar.d ( indexl ) := temu(index); 

indexl := indexl + l; 
index := index + i; 
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end LOOP; 



loop to fill filename 1 

index := index + 15 
indexl := l; 

while (( charac ter 'pos ( temp ( index ) } /= 32) and 
(indexl < 9 ) ) LOOP 

ch_out . file_namel ( indexl ) := temp (index ) ; 
indexl := indexl + l; 
index := index + l; 
end LOOP; 

loop to fill filename 2 

index : = index * 1 ; 
indexl : = 1 ; 

while (( cha rac ter 'post temp ( index ) ) /= 32) and 
( indexl < S ) ) LOOP 

ch_out . file_name2 ( indexl } := temp (index ; ; 
indexl := indexl + i; 
index := index + l; 

end LOOP; 



SNE convert? 
INE files; 
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WITH agate, agatej, arl, slit, alitj, strlit, util; 
PACKAGE files IS 



USE agate, agatej, arl 



MAX USERS 
MAX_FROC 
MAX_LI NSS 

MAX_NUMEER OF_FILES 

MAX_INPUT_CHSAR 

IN IT IAI_FREE_SEGMENT 

INITIAL FRIE_ENTRY 

INITIAL_FREE_MENTOR 

LAST_FREE_SECrMFNT 

LAST _ FREE _EN TRY 

LAST_FREE_MENTOR 

SEGMENT_LENGTH 

MAX _ LEV ELS 

TOF_ SECRET 

c Z rv 7T 

CONFIDENT IAL 
UNCLASSIFIED 



alit, a 



CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT- 

CONSTANT 



it j , str 



integer 
i n teger 
in teger 

— | 

i n tege r 

in tege r 
i nteger 
integer 
in tege r 
integer := 
integer := 
integer :~ 
i nteger 
i n tege r : = 
— max . 
integer := 
integer := 
integer := 
integer := 



, util; 



= 4; 

= 100; 
x. records 
= 2i; 

= 50; 

= 31; 

= 0 : 

= 25 '; 

51; 

11; 

30; 

5008; 

4; 

security 
i; 

2 ; 

3; 

4; 



for file 



levels 



SU5TYFE segren t_nurrter IS integer RANGE 31.. 51; 



SUBTYPE en try _n urrter IS integer RANGE 0..11; 
SUPTYPE mentor numter IS integer RANGE 25.. 33; 



TYPE rl_taramet er s IS 
entry_staek : 

men t or_ stack : 

seg_numter _s tack : 
entry_c ode 
men t or _code 
seg_numte r_c ode 
entry_data 
men t or _d a t a 
seg_numter_data 
e vn_c oun t 
evn_count_data 
synehr_chld_mentcr 
synchr_chld_stack 
synchr_chld_data 

FND record; 



RECORD 
integer ; 
integer; 

integer; 
integer ; 
integer ; 
integer ; 
integer; 
int eger ; 
i nteger; 
integer; 
integer; 

: integer; 
: integer; 
: integer; 



TYPE rl_pa ram IS ARRAY (l..MAX_PROC ) of rl_pa rame te rs ; 



ne 



TYPE data_record IS RECORD 
da tal : s t ri ng( 50 ) ; 

end record; 

TYPE data file IS ARRAY (l.. M AX LINES) cf data record? 



TYPE seg_info 


I 


S RECORD 


number 


• 

• 


segmen t_number J 


e n t r y s 


• 


en try_number.? 


mentor 


• 

• 


men t or_number ? 


f ile_r.ame 


• 

• 


st ring (6 ) ; 


access_cla 




: access_class J 


next_avail_seg 


• 

• 


segmen t _ number ? 


next_avail_ent 


• 

• 


en try_numbe r ; 


nex t _ava i 1 _ren 


• 

4 


ment or_number ; 



END record; 



TYFE segment header 


IS RECORD 


max files stored : integer? 


next_avail_seg 


: segmen t_numcer ? 


next_avail_ent 


: ent ry_ number ? 


n ex t _ava i 1 _men 


: men t or_numbe r ? 


max_ open _ seg 


: segmen t _number ? 


max_open_en t 


: entry_ number ? 


max open men 


: mentor_numter; 


END record; 


TYPE i npu t_me ssage 


IS RECORD 


i npu t _ one 


: strirgv 50 ) ? 


input_result 


: stri^g(5C ) ; 


input class 


: access class? 


END record; 


TYPE comar.d_line 


IS RECORD 


command 


: st ring (S'? 


f i le_namel 


: st ri ng (8 ) ? 


f i le_name?. 


: string(e) ? 


c omm and _cl ass 


: access_class ? 


re sul t 


: string (50) ; 


END record; 


TYPE segmen t_da ta 


IS RECORD 


s egm_i nf o 


: data_file? 


segm class 


: access class 


END record; 


TYPE file s_da ta IS 


ARRAY ( 0 . .N'AX_K)N , PER_ 



seg 



FILES) 

info? 



of 



TYPE level record IS RECORD 
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it in 



max 

END record; 



access_class » 
access class; 



TYPE user level IS ARRAY ( 0 . . MAX LEVELS) of level 



TYPE user_synchro 
active 
seg_data 
seg_stack 
e vc_da ta 
evc_stack 
END record; 



IS RECORD 

: boolean; 
: integer; 
: integer; 
: integer; 
: integer; 



TYPE users active 



IS ARRAY (1..NAX USERS; of user 



TYPE child resource IS RECORD 



memo ry 
processes 
s egment s 
END record; 



in tege r ; 
integer; 
integer ; 



PROCEDURE t24_ f rm_i n teger ( in_val : in integer; 

b24_val : out t24_type 



PROCEDURE put_ln ( ldev : in integer; 

w_class : in access_class; 
s t r : in string ) ; 

PROCEDURE tlk_scr ( ldev : in integer; 

w_class : in acces s_cl ass ; 
str : in string ) ; 



PROCEDURE get_str ( ldev : ir. integer; 

r_class : out access_cl ass ; 
str : out string ) ; 

PROCEDURE put_str ( ldev : in integer; 

w_class : in access_class ; 
str : in string ); 

PROCEDURE put_dec( ldev : ir. integer; 

w_class : in access_class; 
dval : in integer ) ; 

PROCEDURE put_succ( in_str : in string; 



r ec o rd ; 



synchro ; 



\ • 
/ * 
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dec_val : in integer! 
w_class : in access_class )! 

FUNCTION get_input( eco : in boolean! 





rd_class : in access_class ) RETURN string! 


PROCIDURF 


attarh_tew( IO_PORT : in integer! 

LDEV : in integer)! 


PROCEDURE 


attach_ter( IO_FORT : in integer! 

LDEV : in integer) ! 


PROCEDURE 


load_param{ init : in rl_process_def! 

ch_param : out rl_param) ! 


PROCEDURE 


load_access_class ( init : in rl_proces s_d ef ! 

usr_access : out user_level;; 


PROCEDURE 


load_paraml ( init : in rl_process_def ! 

ch_pararn : out r l_pa rare ter s )! 


PROCEDURE 


lcad_child_act ive(act iv_usr : out users_a c ti ve ) ! 


PROCEDURE 


look_f or_level (usernare : in string! 

password : in string! 
ch_access : in user_level! 
ch_class : out access_class ) ! 


PROCEDURE 


in i t i a 1 i ze_ tab le s ( seg_ table : cut files_data; 

seg_head : out segment _header ) ’. 



FUNCTION check_i f_exi sts_f i le_name ( seg_ table : in filss_data 



PROCEDURE 


f'ile_name : in string) RETURN boolean 

con ve rt ( ch_ i n : i r. inpnt_rressage! 

w _ c 1 a s s : in acc.ess_class! 
ch out : out corrand line )! 



END files! 
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APPENDIX G - SYSGEN SUBMIT FILE (SSBJ 



This appendix contains the description of the Sysgen Submit 
File used to sysgen the entire system, the commands used are : 



bs:ld3.cmd 

ks:k0.cmd 

ks:kl.cmd 

ks:k2.cmd 

cs:vlloader.cmd;2; 

ds:vilogin.cmd;2.10; 

ds:nv.ds;2,5: 

ds:nv.ds;5; 

ds:prmain.cmd:5.0;t: 

ds:puserl.cmd;5.7; 

ds:prchll.cmd;5,7.4: 

ds:puser2.cmd:5.8: 

ds:prchl2.cmd;5,8,4; 

ds:puser3.cmd:5.9: 

ds:prchl3.cmd;5.9,4; 

ds:prbdos.cmd;5,10; 

ds:rltrap.cmd;6; 

end 
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